Release early, Release often

[Karolin Seeger]

On Mon, Apr 27, 2015 at 10:53:42AM +0200, Michael Adam wrote:
> Hi Andrew,
> 
> On 2015-04-25 at 21:06 +1200, Andrew Bartlett wrote:
> > (I started this discussion somewhere else, but it belongs on samba-technical, 
> > so I'm starting it again here)
> > 
> > Since the long-delayed release of Samba 4.2, I have been thinking about 
> > our release process, and I would like to suggest a 4-6 month release cycle.
> > 
> > We agreed back in 2010 (just after 3.5) to move to 9 month release
> > cycles.
> 
> Iirc, I think it would reflect the situation more precisely to say that we
> 
> 1. previously had no fixed release cycle,
> 2. wanted to do releases more frequently and reliably,
> 3. had tried 6 months, saw it did not work out (too much work for Karolin iirc),
> 4. and hence agreed to TRY the compromise of 9 a months cycle
>    (because we did not want to go to 12 months)
> 
> > However, I think that '9' month release cycles are hurt us more
> > than they have helped.  Since 2010 our last release cycles have lasted
> > 17, 16, 10 and 15 months!
> 
> Right, this has not really worked out well.
> Mainly due to delaying for features as you point out.
> 
> > Moving to a 4-6 month release cycle means that we would stop holding up
> > releases for features that 'can't wait for the next release', because it
> > will be along soon enough.  
> > 
> > I'm mindful of the load on Karolin, but it should be less stress because
> > we certainly won't be waiting for features that are not already finished
> > in master, and the shorter RC releases should only be addressing actual
> > regressions, not backported features that really belong in the next
> > release.
> > 
> > For Samba 4.2 in particular, this release not only started quite late -
> > we cut rc1 a full year after 4.1, but we kept on waiting and waiting for
> > a feature (leases) that wasn't in master at the time we wanted to
> > freeze, and we kept chasing that almost right to the end.
> > 
> > The position I have is that, now that we are past the disruptive time of
> > the 4.0 merge, we just shouldn't be waiting for features.  We should
> > instead have a much more 'linux-kernel' release schedule, making new,
> > production releases on a time-frame measured in months, not years.  
> > 
> > We need a much higher release velocity to give our users and customers
> > confidence that even if a feature is on the Roadmap as under active 
> > development, or that if a feature is in master, that it will soon be 
> > in a release.  
> > 
> > We have managed 6 month releases in the past, between 3.2, 3.3 and 3.4.
> > It was only after taking 9 months to do 3.5, and that decision at
> > SambaXP 2010, that the timeframes started to really extend.
> 
> I agree with most of what you are writing!
> We should not be blocking releases for features anyways.
> Especially from a developer's point of view, more frequent
> releases would make that much more bearable (4 months better
> than 6 from that pov).
> 
> But I think there two major concerns to be resolved:
> 
> 1.) load on release management:
>     - At least this was the reason to move from 6 to try 9 months, iirc.
>     - One could argue that a slimmer release process would
>       ideally reduce the load on release management for each
>       individual release.

There were times we did not have enough new features for major releases.
Release notes were pretty short.
 
> 2.) lifetime of a releases:
>     - Currently we have >= 9 months of major stable release,
>       >=9 months of maintenance mode and  >= 9 months of
>       security mode, hence >= 27 months of lifetime of a release.
>     - With 4 months cycle we would be down yo 1 year of
>       lifetime for a release.
>     - The question is how nice this would be for the distributors
>       and vendors, that like to rely on long term supported
>       versions.
>     - Hence the question (that has already been raised) whether
>       we'd need to add long term support (LTS) releases, which
>       would again raise the amount of work needed for releases.
>       ==> Can we do without having LTS releases and leave that
>           maintenance to the distributors and vendors???
> 
> My thoughts so far...
> 
> Cheers - Michael
> 

Cheers,
Karo

-- 
Samba			http://www.samba.org
SerNet			http://www.sernet.de
sambaXP			http://www.sambaxp.org