[Development] Setting up time-based releases for the project

[lars.knoll at nokia.com]

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.

A few notes from my side: 

* Any release should be done directly from the stable branch, using a tag.
* 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.
* 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.
* 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.

Cheers,
Lars


On Aug 7, 2012, at 2:45 AM, ext Alan Alpert <alan.alpert at nokia.com> wrote:

> On Mon, 6 Aug 2012 22:13:30 ext joao.abecasis at nokia.com wrote:
>> Fire-hose is a development branch, things may be variously broken at all
>> times. Typically, developers in this mailing list will be tracking that
>> branch.
>> 
>> Leaky-faucet is deemed beta quality and somewhat more stable. At the very
>> least it shouldn't break as often. We can expect that more people will be
>> willing to track this branch with their own development.
> 
> This is the part that I don't quite understand. This makes it sound like Fire-
> hose is the branch for destabilizing changes. Particularly destabilizing 
> change sets are of course in their own branch, but the large numbers of 
> normally destabilizing changes will make fire-hose mere Alpha quality at best. 
> But then Thiago's email then said that fire-hose should be 'always ready for 
> beta', which seems contradictory.
> 
> As I interpret it, the bump in quality comes from merging fire-hose to leaky-
> faucet some time before the release. Unfortunately, I didn't get any extra 
> detail when I zoomed in on your ascii art. Here's my zoomed in version of the 
> diagram:
> 
> ----------+----------------- fire-hose
>           \
> ----------+---------+------- leaky-faucet
>                     \
> --------------------+------+ dripping-bucket
>                           \ 5.1.0
> ~2 Months |-----------------|
> 
> Note that we also seem to disagree on the time scale, but that's what '~' is 
> for ;) . Am I correct in assuming that merging fire-hose to leaky-faucet drops 
> the quality of leaky-faucet to whatever fire-hose may be, and then developer 
> focus shifts to leaky-faucet for stabilization (while destabilizing elements 
> continue to flow rapidly into fire-hose for the next release)? How much lead 
> time do we allocate per release? And what happens if we slip, because we 
> couldn't get it to beta quality in time?
> 
>>> If we move the release testing onto leaky-faucet, then dripping-bucket
>>> contains only the latest release, with at most a critical patch or two.
>> 
>> That depends on whether we consider that typical patch release traffic has
>> an impact on release readiness. (Can bug fixes introduce new regressions?
>> :-)
> 
> When applied in haste? Roll a d20 :P . More seriously, it sounds to me like 
> dripping-bucket is just there for the release manager to have a further 
> measure of control. But if that's where the packages are generated from, 
> that's where the release testing will happen no matter how few patches we try 
> to accept on top.
> 
> On a less important aspect, can we use less metaphorical names? master, beta, 
> release perhaps? trunk, stable, release-managers-private-stash? I don't like 
> starting the bike shedding part early, but since your metaphors aren't really 
> working for me I think other names might allow for more clarity.
> 
> --
> Alan Alpert
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development