Hi
Dne 25.5.2016 v 21:45 Isaac Bennetch napsal(a):
Currently, the release instructions prompt me to create a MAINT branch for each release. That way, if we have a security fix for 4.6.2 we can go to MAINT_4_6_2 and perform the work there. I think this is overkill -- for instance, we haven't done a patch-level security release on 4.6.0 or 4.6.1.
If we need to do a security release, we can create the MAINT branch later:
git checkout RELEASE_4_6_2 git checkout -b MAINT_4_6_2
I'm proposing that we stop creating MAINT branches for each release. This isn't something I feel particularly strongly about, so I could be convinced to withdraw my proposal, but I don't see much value in maintaining MAINT branches we aren't using.
I think this is sensible approach. I think in past MAINT branches were created before release, so that the maint branch would stabilize before release and fixes would go to QA branch in that time. On the other side this just increases round trip for the fixes and I don't think MAINT branch did get any reasonable amount of user testing before release, so it didn't really bring expected benefits...
A side-effect of this is that currently, the demo server has STABLE, QA_4_6, and MAINT_4_6_2 [1]; QA_4_6 will change until our next release and STABLE and MAINT_4_6_2 will remain the same unless we need to release a 4.6.2.1, in which case both would be updated. For the demo server, I may be missing a scenario but don't see how the current MAINT and STABLE would differ, meaning we can remove MAINT from there as well.
Sounds fine and saves work on every release :-).