[phpMyAdmin Developers] creating MAINT branches for each release

[Michal Čihař]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.phpmyadmin.net/pipermail/developers/attachments/20160526/f7d4929f/attachment.sig>