[Releasing] rethinking the branching scheme

[Heikkinen Jani]

> -----Original Message-----
> From: releasing-bounces+jani.heikkinen=digia.com at qt-project.org
> [mailto:releasing-bounces+jani.heikkinen=digia.com at qt-project.org] On
> Behalf Of Ziller Eike
> Sent: 19. helmikuuta 2014 18:35
> To: Gladhorn Frederik
> Cc: releasing at qt-project.org
> Subject: Re: [Releasing] rethinking the branching scheme
> 
> 
> On Feb 19, 2014, at 3:19 PM, Frederik Gladhorn
> <frederik.gladhorn at digia.com> wrote:
> 
> > Hi,
> >
> > as one of the people involved I agree that the current system is pretty
> > broken. But I think we need to solve several issues and should attempt to
> do
> > it incrementally.
> >
> > Discussion points:
> >
> > 1. defining which patches are the branching points
> > 2. awareness of branches (is it needed? we hope not, that's why we have
> dev
> > and stable branches)
> > 3. reluctance/inability to create patch releases
> > 4. ease of contributing to Qt for casual developers
> > 5. problems when merging branches
> > 6. branch model and CI configuration
> >
> > While I initially was very much for Ossi's proposal, I'd like to explore a few
> > points for and against it. Maybe we can end up with something less
> radical.
> >
> > Here are my thoughts to the issues listed above:
> >
> > 1. See my sha1 proposal mail.
> >
> > 2. This is a mixed thing. Ideally everyone knows to push to dev/stable.
> > Pushing to the release branch is the exeption and can in my opinion be
> much
> > harder as it should really not happen usually.
> > If a fix for a release is needed, we can demand that the person pushing the
> > fix knows more (for example a branch name).
> 
> > 3. My impression is that we don't release enough patch releases. The
> reason is
> > probably not simple. I suspect that we make the whole harder by not
> having
> > branches, so we don't even see if a release is worthwhile and we don't
> > encourage patches that would go into 5.1.x since there is basically now
> way to
> > contribute them. This is also problematic for security fixes.
> > On a technical level it's trivial to create a branch from any tag/sha1, but it
> > seems to be a more social problem to me.
> > Maybe having dev/stable/5.2/5.3/5.4 branches would make this easier.
> > Other issues are of course that each release has a big cost in QA and
> > packaging etc.
> 
> To create a release from a sha, you need to know the sha.
> Current stable (up to the merge from dev) contains fixes for tasks that are
> now closed with fix version Qt 5.2.2. If we never do a 5.2.2 release that
> doesn't really matter, but if we do a 5.2.2 release it should contain these
> fixes, e.g. it should be done from "current stable" (plus maybe some
> patches, who knows).
> We have to "remember" that sha. A natural way to do that is to have it as
> HEAD of a 5.2 branch. I think if we have to start digging for what sha to
> release as a 5.2.2, we will for sure not do it. For as long as we do not use the
> release branch for alpha releases (actually why don't we?), and didn't do a
> beta release for the new minor release yet, the release  branch can be used
> to cache the "potential 5.2.2" (that's still pretty non-obvious btw). But the
> moment the release branch is used for anything else, the sha is just some
> sha in some tree of trees...

Release branch is the "potential 5.2.2" at the moment, that's why we merged stable to release before dev to stable