[Development] Proposal: removing the release branches after the release
oswald.buddenhagen at digia.com
Tue May 27 09:26:38 CEST 2014
On Tue, May 27, 2014 at 06:25:37AM +0000, Knoll Lars wrote:
> On 26/05/14 21:59, "Thiago Macieira" <thiago.macieira at intel.com> wrote:
> >I've just seen that all the Qt repositories got a 5.3.0 branch
and they lost the release branches a minute later. it was a renaming.
> >(including those for which a release not called "5.3.0" was
yeah. minor mistake. ^^
> >I'm proposing to reverse that. There's no point in having those branches,
> >since after the code is tagged and released. There will never be any
> >change to
> >the code under that same version number.
> >If there's any need to make an emergency release on top of a given tag,
> >release will get a new version number (without dashes, please) and we can
> >create a branch with the appropriate name to make the release. And once
> >is done, we remove the branch again.
> I don’t see any problems with having named branches for patch level
> releases, and it is what we agreed to some months ago. Can you explain why
> you’d want to remove the branches once the release is done?
let's say it's a measure to keep the admins halfways sane. ^^
a release branch is redundant with the tag which marks its end.
one can also argue like that: we have the policy that closed wip
branches should be deleted (which, btw, needs to be followed more
closely). but then: why limit this to wip branches?
of course, one could argue that minor/stable branches (5.3) should also
be deleted once they are pronounced dead (a year or two after being
superseded), but that's marginal gains.
More information about the Development