release schedule proposal

[Cyrille Berger Skott]

On Wednesday 02 February 2011, Jaroslaw Staniek wrote:
> We have to plan branching rules for this, or is tagging the master our
> way (+feature branches)? Whatever works for you.
I wanted to discuss this at the sprint :)

My idea was to have feature branches. And trying to have feature branches have 
a as limited scope as possible, so that they can be merged quickly, but once 
reasonnably finished. Some time before the actual release (between 4 to 6 
weeks), master is branched, into a "X.Y" branch, bug fixes are made in the 
"X.Y" branch and merged back into master. When the "X.Y" branch is ready, it 
is released (and in the mean time we publish beta/rcs based on that branch).

And also. My idea is to four feature releases per-year. One "main" release, 
with what we could call "long-term" support, released for instance in 
February. For this release the community provide bug fixes release for one 
year, security fixes for an other year. And then every three monthes we have 
features release. The "main" or LTS release is advised for long support 
distributions such as Red Hat, Ubuntu LTS, Debian or Novell Desktop. While the 
"feature" releases are advised for dynamic distributions such as Fedora, 
OpenSuSE, or regular Ubuntu.

That is a short summary of what I would suggest and use as a starting point 
for further discussions.

But in any case, the current plan was to have more "classical" release until 
we are user-ready.

-- 
Cyrille Berger Skott