release schedule proposal

[Boudewijn Rempt]

On Wednesday 02 February 2011, Cyrille Berger Skott wrote:
> 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 :)

:-). But the sprint is far away and I want something to replace the KOffice 2.3.2 release with...

> 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 
> reasonnaly finished. 

Personally, I'm amazed to see how quickly this actually has started to happen, and how well it seems to work!

> 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.

Yes, that's what I want to achieve as well -- but until we have software that's good enought I want to change from this plan:

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

to frequent snapshot releases made from master that we can confidently label as stable, since only finished features and bug fixes land there.

-- 
Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org