[Development] Proposal: removing the release branches after the release

[Oswald Buddenhagen]

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
> >produced).
> >
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,
> >that 
> >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
> >that 
> >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.