[Releasing] rethinking the branching scheme

Heikkinen Jani Jani.Heikkinen at digia.com
Wed Feb 19 17:42:00 CET 2014

> -----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

More information about the Releasing mailing list