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

[joao.abecasis at nokia.com]

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