[phpMyAdmin Developers] About branch maintenance

Sebastian Mendel info at sebastianmendel.de
Tue Feb 1 11:30:54 CET 2022

Thanks Isaac for bringing this up,

I agree on:

- dropping "" 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.


Am Sa., 22. Jan. 2022 um 01:53 Uhr schrieb Isaac Bennetch <
bennetch at gmail.com>:

> 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 or
> 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 at phpmyadmin.net
> https://lists.phpmyadmin.net/mailman/listinfo/developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.phpmyadmin.net/pipermail/developers/attachments/20220201/ff0819da/attachment.htm>

More information about the Developers mailing list