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 :-).
--
Michal Čihař |
http://cihar.com/ |
https://weblate.org/