This is a discussion on RE: Timed releases, versions, etc... [was Re: Freeze proto.h?] - Samba ; I used to use a system called aegis. In conjunction with enforced test suite expansion I became possible to rele= ase a sound codebase at any time, one that passed all the tests. http://aegis.sourceforge.net/ Possibly such a system is not ...
I used to use a system called aegis.
In conjunction with enforced test suite expansion I became possible to rele=
ase a sound codebase at any time, one that passed all the tests.
Possibly such a system is not a solution - while it would support regular r=
elease it would not provide early or predictable presence of new features i=
n the releases which is resumably what advocates are looking for.
I don't know if aegis has a git backend and I'm not recommending it for Sa=
mba, I just used it to illustrate the point.
From: Jim McDonough
Sent: 22 April 2008 08:15
To: Christian Perrier
Subject: Re: Timed releases, versions, etc... [was Re: Freeze proto.h?]
On Tue, Apr 22, 2008 at 1:47 AM, Christian Perrier
> I think that 6 month release timeframe is very ambitious....maybe too
Perhaps, but sometimes you have to learn the hard way...
> I'd love to be proven wrong but my general feeling is that, even with
> (what I understand to be) the obvious commitment of SerNet to directly
> or indirectly pay someone so that Samba releases happen, things can
> change during time....and, still, that makes the release management a
> huge work....therefore having a 6-month release cycle really hard to
So one of the key points Jerry makes is that it will take a lot of
discipline...but in what, specifically? One of the goals is to
provide reduced differences between releases, and I think this is the
part that will take quite a bit of discipline, but will provide better
results. Developers don't want to support code from even one release
prior because there can be major differences between the releases.
This change could make it easier both for users to upgrade, and
developers to support code older than the latest release only.
But it will definitely require a mind shift from the "Wait, we have to
have _my_ major piece" mode that currently dominates scheduling of
releases. The developer who writes the code has to decide if the code
will be ready for the schedule, rather than delaying the schedule (and
everyone's code) until the code is ready.
jmcd at samba dot org
jmcd at themcdonoughs dot org