Hello team,
In the past, once a release entered the LTS phase with fixes only for security issues, we would switch from the QA branch to a MAINT branch and releases would have a patch level (such as 4.0.8.1). Since we no longer do patch-level release numbers, to be more consistent with Semver and some of the tools we use, we should decide how to handle these LTS releases.
It often doesn’t make sense to merge QA_4_9 in to QA_5_0 because of changed file names and different function declarations. Even though the fix is often similar, it doesn’t always merge very well (one example we’ve seen several times lately is the change in array declarations from (IIRC) [ … ] to array( … ).
Would it benefit us to maintain a MAINT_4_9 branch that is meant to NOT merge to QA_5_0. In that case, a security issue would need two pull requests/commits, one for MAINT_4_9 and one for QA_5_0 (soon to be 5_1 anyway). I think that especially with the upcoming release of 5.1 this might make maintenance easier for us.
Em dom, 18 de out de 2020 09:58, Isaac Bennetch bennetch@gmail.com escreveu:
Hello team,
Hello
In the past, once a release entered the LTS phase with fixes only for security issues, we would switch from the QA branch to a MAINT branch and releases would have a patch level (such as 4.0.8.1). Since we no longer do patch-level release numbers, to be more consistent with Semver and some of the tools we use, we should decide how to handle these LTS releases.
It often doesn’t make sense to merge QA_4_9 in to QA_5_0 because of changed file names and different function declarations. Even though the fix is often similar, it doesn’t always merge very well (one example we’ve seen several times lately is the change in array declarations from (IIRC) [ … ] to array( … ).
Would it benefit us to maintain a MAINT_4_9 branch that is meant to NOT merge to QA_5_0. In that case, a security issue would need two pull requests/commits, one for MAINT_4_9 and one for QA_5_0 (soon to be 5_1 anyway). I think that especially with the upcoming release of 5.1 this might make maintenance easier for us.
I think that makes sense and I agree.
_______________________________________________
Developers mailing list Developers@phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers
Hello team,
I agree to use a MAINT branch to commit security fixes and some un-mergeable fixes.
But: I would suggest that we always merge branches. After all fixes are done, to keep a better history in case no conflicts would appear or only simple ones.
Example: fix on branch MAINT, empty merge, fix on other branch
Example: fix on branch MAINT, merge the fix, end.
William Desportes
---- Le lun., 19 oct. 2020 15:11:30 +0200 Maurício Meneghini Fauth mailto:mauriciofauth@gmail.com écrit ----
Em dom, 18 de out de 2020 09:58, Isaac Bennetch mailto:bennetch@gmail.com escreveu:
Hello team,
Hello
In the past, once a release entered the LTS phase with fixes only for security issues, we would switch from the QA branch to a MAINT branch and releases would have a patch level (such as 4.0.8.1). Since we no longer do patch-level release numbers, to be more consistent with Semver and some of the tools we use, we should decide how to handle these LTS releases.
It often doesn’t make sense to merge QA_4_9 in to QA_5_0 because of changed file names and different function declarations. Even though the fix is often similar, it doesn’t always merge very well (one example we’ve seen several times lately is the change in array declarations from (IIRC) [ … ] to array( … ).
Would it benefit us to maintain a MAINT_4_9 branch that is meant to NOT merge to QA_5_0. In that case, a security issue would need two pull requests/commits, one for MAINT_4_9 and one for QA_5_0 (soon to be 5_1 anyway). I think that especially with the upcoming release of 5.1 this might make maintenance easier for us.
I think that makes sense and I agree.
_______________________________________________ Developers mailing list mailto:Developers@phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers
_______________________________________________ Developers mailing list mailto:Developers@phpmyadmin.net https://lists.phpmyadmin.net/mailman/listinfo/developers
-
Isaac Bennetch -
Maurício Meneghini Fauth -
William Desportes