[phpMyAdmin Developers] About branch maintenance

[William Desportes]

Hi,

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

I disagree on this part, history is important and I want to keep it 
alive and non interrupted as long as possible.
That said: Weblate generate very large diffs (unless I am mistaken), 
maybe this point could be discussed to start having a lighter history in 
the future.

> - do not accept translation updates for MAINT_X_Y
> - accept only rebased PR

Translations are managed by Weblate, I would agree disabling them for 
non supported versions but for now except new languages it does not make 
any harm.

> - 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 agree

> -- 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

I can not agree for historical and technical reasons, tag should not be 
changed as they are GPG signed.

> - 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 prefer continuing to do merging unless the code bases are too 
much different (for example 4.9 and 5.1).
Then cherry-picking is a good solution, but I would really note that for 
security research it is very important to know where the commit is 
from.. (like a merge would let the user know). For the record I often 
have to search when commits where added, for what reason and if they 
where added on other branches too to give references to the Debian 
security tracking tool (or team). Identifying the affected versions are 
a big part of this cherry-pick topic.

William
Le 2022-02-01 11:30, Sebastian Mendel a écrit :
> 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 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 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 at phpmyadmin.net
>> https://lists.phpmyadmin.net/mailman/listinfo/developers
> _______________________________________________
> Developers mailing list
> Developers at phpmyadmin.net
> https://lists.phpmyadmin.net/mailman/listinfo/developers