Release early, Release often
kseeger at samba.org
Mon Apr 27 13:29:43 MDT 2015
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
> - 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
More information about the samba-technical