Thanks Isaac for bringing this up,
I agree on:
- dropping "4.9.0.1" versioning scheme in favour for correct semantic
versioning: X.Y.Z
-- and sticking to RELEASE_X_Y_Z_ as tag name scheme
-- I would even agree on renaming old tags from "X.Y.Z.0" to
RELEASE_X_Y_Z", or drop them if they are duplicates
- having only one branch per minor version for maintenance
-- with MAINT_X_Y as scheme
-- master/main diverges into MAINT_ on feature freeze for next major release
- not/never merging from MAINT_X_Y
-- just cherry-picking if required/suitable.
I would also suggest:
- do not accept translation updates for MAINT_X_Y
- accept only rebased PR
all for a better acceptance by (new) developers and maintainers
For a better acceptance by (new) developers and maintainers, I would also
suggest/agree on "dropping" (archiving in a separate repo) a large portion
of git repo history - currently a (new) contributor has to download ~1.15
GiB of data.
Sebastian
Am Sa., 22. Jan. 2022 um 01:53 Uhr schrieb Isaac Bennetch <
bennetch(a)gmail.com>gt;:
Hi,
It has occurred to me that our current branches have diverged
significantly from QA_4_9 and that our current system of merging any change
from QA_4_9 to QA_5_1 then to master doesn't seem ideal to me any longer.
This makes security merges difficult.
This got messy at the point where we decided to continue supporting 4.9
for urgent fixes and security fixes, because prior to 4.9, security fixes
would generally be assigned a fourth version number (such as 2.11.2.2 or
4.1.14.8). That fourth version number does not conform very well with
semver and we've adapted to releasing a new "patch" release for security
fixes (4.9.7, for instance). Under the older system, a branch MAINT_4_1_14
would be created for the security fixes for 4.1.14.x, because a QA_ branch
would get merged ahead to newer branches but the MAINT branch was not meant
to be merged. Similar changes could be git cherry-picked to future branches
instead.
Here's what I'm proposing:
* Make a break from merging QA_4_9, remove the QA_4_9 branch and replace
it with MAINT_4_9 (not MAINT_4_9_8, which would be the old way). We're
really getting towards the end of wanting to support 4.9 anyway, but this
will allow us to maintain 4.9 without complicated merges to the 5.x
branches. It's easy to see how we got in this situation because at first we
were still sort of supporting 4.9 for bug fixes and slowly switched to
security only, but this is a good time to commit to doing this the right
way.
As a reminder, since we're releasing 5.2.0-rc1, QA_5_2 is going to be
created from master, and QA_5_2 will be frozen for new features; it will
become bug fix only. Once 5.2.0 is officially released, QA_5_1 will be
removed. I don't believe this will cause any problems with compatibility
with very old PHP versions as there should be significant overlap.
Regards,
Isaac
_______________________________________________
Developers mailing list
Developers(a)phpmyadmin.net
https://lists.phpmyadmin.net/mailman/listinfo/developers