[Development] Setting up time-based releases for the project
joao.abecasis at nokia.com
joao.abecasis at nokia.com
Tue Aug 7 11:15:20 CEST 2012
On 7. aug. 2012, at 10:10, ext lars.knoll at nokia.com wrote:
> In general I like the model. As Thiago said it's pretty close to what we've been discussing internally before we started Qt 5 development.
> I agree that we should kickstart the model after the beta release. Branch names should be more concrete and for outsiders to understand, so I'm with Alan to give then easy to understand names. My proposal would be master, beta and stable.
I have no qualms about the names. I still had to propose something ;-)
> A few notes from my side:
> * Any release should be done directly from the stable branch, using a tag.
Yes, this was implied, but could have been explicit.
> * When going for a new minor release, we merge master to beta. This happens ~every 6 months.
> * A new patch level release is released from stable when we see a need. I don't think a strict 2 month policy will work here, esp. when we e.g. have a security advisory we need to release a fix for.
I would still like to have a strict time-based patch releases as it sets the pulse for the project and gets code out without an additional decision process. (The ~2 month suggestion can be adjusted, though)
Security issues are exceptional cases and need to be handled accordingly, but most of our patch releases are not in that category. I would expect we take the previous patch release, add the fix on top and release immediately; alternately we take the current stable branch, add the fix on top and release immediately with whatever else was there at the time.
My main concern is that allowing too much leeway in how we handle patch releases will have an impact on the minor release schedule. If we are to make time-based releases work, we need to go all in and deal with exceptions with exceptional measures.
> * After a patch level release, we merge beta to stable, and then start testing release again, fixing any issues the merge might have introduced.
> * Depending on our policies, we might never need to merge back from stable to beta to master. Policy could simply be that beta and stable only cherry-pick changes from master, in which case there's no need to ever merge back.
This adds extra work in that someone needs to select and hand pick individual fixes to go in the beta branch, or the committer has to go through an additional round of review for the cherry-pick. Allowing the developer to directly commit the fix to the right branch minimizes this overhead at the cost of the occasional merge.
> * For security issues we might need to also offer patches for older releases (if we're at 5.2.x, we might still need to apply the fix to latest 5.1 and 5.0. This can be done by creating a dedicated 5.1-security branch on top of the latest 5.1 release tag and applying the fix there. This should make it possible to do these kind of releases in a fast and efficient way.
We can always go back and branch out of the last patch release in a series for security issues. That is outside the scope of the current proposal, as the common branches move on and are not tied to specific releases.
More information about the Development