> -----Original Message----- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Ziller Eike > Sent: 19. helmikuuta 2014 18:35 > To: Gladhorn Frederik > Cc: [email protected] > Subject: Re: [Releasing] rethinking the branching scheme > > > On Feb 19, 2014, at 3:19 PM, Frederik Gladhorn > <[email protected]> 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 _______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
