On 1/27/06, Julian Foad <julianfoad@btopenworld.com> wrote:
> If we can't find an archive of that discussion, maybe we'll have to have it
> again. Obviously there is merit in that approach, but I get the impression the
> shorter release cycles are more generally favoured.
As I said before, I think 3-4 months between minor releases is too
short. Given that we have roughly two months of soak, it means that
we only get one month of development after the minor release before
the next branch is frozen.
It's not like our time is truly parallelized and all of us can do
trunk work while we're soaking. Those of us who help out during the
release (like me) focus for those periods on getting the release
stabilized and are not able to do much trunk development.
This also places an extreme burden on the RM team to keep a bunch of
releases alive concurrently. Switching to three month cycles means
that we now do one of the following:
- support a whole bunch of release series at the same time (1.2.x,
1.3.x, 1.4.x, etc.)
(thus, the lifetime of a release series is still roughly 6-9 months)
OR
- establish that we'll only do patch releases for 3 months on a release branch
(thus, the lifetime of the release series is only 3 months)
Right now, we only keep one release branch open: i.e. once we push out
1.3.0, we stop 1.2.x patch releases. Are we willing to keep more
branches open or shorten the lifetimes of the branches?
I think our current spacing makes sense: that is, we go about 6 months
between minor releases and do roughly (give or take) monthly patch
releases to fix bugs with the last minor release. We give folks
'stable' upgrades that just delivers fixes - but no new features.
This also means that a release series is supported for roughly 6
months. An admin gets stability and predicatability rather than
chasing a continuously moving target. If they find a bug four months
into the cycle, they have a 'stable' upgrade available that just gives
them bug fixes. Going to the four month plan, they need to take a
whole bunch of new features that'll do who knows what.
> Imagine we were doing a yearly cycle. We have just put out v1.3, so Serf will
> have to wait for the January 2007 version 1.4. Would you honestly feel happier
> with that, in your current situation, than with just-missing May 2006 and
> having to wait for September instead?
Our pattern has been for roughly twice-yearly release cycles.
Therefore, we're talking about not allowing any changes made after
January 2006 to be released until late 2006 or early 2007. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 28 02:11:02 2006