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

Hello Qt-ians, While releasing Qt 5.0.0 is an ongoing process, I think this is a good time to start planning future releases (5.0.1, 5.1.0, etc.) and, most importantly, we need to discuss *how* we'll get them out on time. With the setup we now have we should quickly move to a strict time-based release schedule. A predictable schedule allows all interested to align with the project and contribute to make the next release the traditional Best Release Ever (tm) of Qt. In this regard, there has been mention of a 6-month release cycle for minor releases. Thus far, I think there is wide agreement. What I feel is missing is a setup that actually gets us there. I'd like to bring up to this list and propose for adoption a development model that is meant to support time-based releases. This model would apply to qtbase and qtdeclarative, primarily. Other repositories can decide to follow on their own. * TL;DR -+--------------------------+---------------------- fire-hose \ \ -+-+------+--------+--------+-+------+--------+---- leaky-faucet \ \ \ \ \ \ -+-+------+-+------+-+------+-+------+-+------+-+-- dripping-bucket \ \ \ \ \ \ 5.0.1 5.0.2 5.1.0 5.1.1 5.1.2 5.2.0 ~2 months |--------| (patch release) ~6 months |--------|--------|--------| (minor release) * The setup There are three common development branches in git: fire hose, leaky faucet and dripping bucket. The names are metaphors for the amount of development expected to happen on each branch. Branches are open for changes at all times. There are commit policies in place that govern *what* is allowed in each one and *how* to get changes in. * The branches The three branches define a progression of decreasing rate-of-change and thus increasing stability. - Fire hose - the main development branch. It supports the minor release cycle. The commit policy allows for features and bug fixes. Changes must support BC promises for minor releases. This is the default branch for all changes. - Leaky faucet - supports the patch release cycle. Bug fixes are accepted for regressions against the previous minor release. Changes going in must support forward and backward BC promises of patch releases. - Dripping bucket - this branch supports the (immediate) release process. Release critical bug fixes are accepted, potentially requiring approval from the Release Manager. This is the branch releases are made out of. Put another way these are the Alpha, Beta and Release Candidate branches. * Branch integration Merges down the ladder (i.e., fire-hose -> leaky-faucet and leaky-faucet -> dripping-bucket) happen on a regular schedule. Merges up the ladder may happen at any time, as deemed necessary. Fire-hose to leaky-faucet merges initiate the minor release cycle, they're essentially equivalent to a feature freeze for a minor release. Leaky-faucet to dripping bucket merges initiate the release process, they're equivalent to branching off for release. In a sense, changes graduate through the branches to make it to a release. * Releases In this proposal minor releases happen every 6 months, with patch releases occurring every 2 months. In terms of the source repository, releases are taken from (and tagged in) the dripping-bucket branch. Branches "roll" from supporting one release to the next. Also part of this proposal, the number of patch releases supported by the Qt project is fixed. Each minor version gets 3 patch releases: 5.x.0, 5.x.1 and 5.x.2. A lifetime of 6 months. Downstream distributors that wish to offer longer term support on specific releases are encouraged to maintain their own branches beyond what the Qt project offers. * Bootstrapping +------------------- fire-hose / master -----+------+--------+----- leaky-faucet \ \ \ +----+-+------+-+--- dripping-bucket \ \ 5.0.0 5.0.1 After the 5.0 Beta is out we create three (initially identical) branches and take the new model for a spin, establishing and enforcing branch commit policies. Assuming a Beta release sometime this month, we would aim for 5.0.0 release somewhere in September/October and start the clock ticking from there, aiming for a 5.1.0 release around April 2013. I believe this captures the gist of it, while there is still plenty of details to be hammered out -- like concrete actionable policies and what (if anything) do we do to enforce them. What do others think? João