Release early, Release often

[Nico Kadel-Garcia]

On Sat, Apr 25, 2015 at 5:06 AM, Andrew Bartlett <abartlet at samba.org> 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.

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

Anything that can help reduce the quite large discrepancies between
the 4.2.0rc3 and the 4.2.0 release would be helpful. It was a bit of a
shock, at least to me as a casual integrator, when so many libraries
had "-samba4" added to their names and my samba-4.x building tools for
RHEL 6 had to be extensively rewritten.

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

It's also much easier to test a smaller set of changes, and for
individual operating systems to skip a smaller release if they need
to. I'm thinking of stable systems like RHEL, and its progeny CentOS
and Scientific Linux. If the release cycle is really long, and Samba
happens not to occur during the window of opportunity before the
operating system feature freeze, then the distributed version of Samba
for RHEL can be effectively locked until the *next* major RHEL
release. And that one will remain likely to be locked on an out of
date version, and the cycle will repeat.

> 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.
>
> Thanks,
>
> Andrew Bartlett

It would make my life easier publishing backports to RHEL 6: smaller
changes are much easier to integrate. (I did mention the library
renaming fun and games with 4.2.0 which were not in 4.2.0rc3). They're
easier to smoke test, they're much safer to roll back, and they help
to teach the new staff how to do upgrades while the last generation of
staff are available to provide eminent wisdom. Moreover, as someone
who's been bopping around as a consultant a lot for the next 10 years
and dealing with Samba for about 20, it would help my clients take
advantage of my experience while I'm available to help out.

So yes, please: shorter release cycles would be nice.

                           Nico Kadel-Garcia