Schedule for releases

[John Baldwin]

On Tuesday, December 21, 2010 5:59:24 pm Poul-Henning Kamp wrote:
> In message <alpine.BSF.2.00.1012212215320.36028 at fledge.watson.org>, Robert Wats
> on writes:
> 
> >Looking at 7.x, I'm struck by how much it has slowed down.  There's a 
> >significant user community, but not a significant developer community.
> 
> This is a very important point to interpret correctly:
> 
> 	FreeBSD is whatever its developers make it be.
> 
> If there are no developers who has an interest in MFC'ing back to 7.x,
> MFCs will not happen, no matter how much we talk about it.

There is a fly in the ointment here though in that some developers _do_ have
an interest in doing MFC's to 7.x and having a longer 7.x branch (for
example).  However, our current release structure makes that more painful
since you have to merge changes across three branches.  If .0 releases were
more spread out then supporting 7.x would no longer meaning supporting 3
active branches, but back to just 2 branches.  For much of the problems I
need to solve at work, I am developing on 7.x (since that is what we use
currently) and then "forwardporting" two branches forward to 9.

> Trying to force developers to maintain multiple branches will not work,
> they have to take an interest.

Yes, but if we chose to have longer -stable branches we could also adjust our
release schedule to compensate.  We have _chosen_ this current model of
relatively short -stable branches and frequent X.0 releases.

> Companies who use Open Source are not adverse to paying for the
> service they get, but somebody needs to make it easy for them.

You should be careful to not ignore the feedback of companies who already
_are_ paying for this service in some fashion (e.g. by employing committers
who are allowed to participate in the community as well such as mdf@ or
myself).  These companies are already doing that, but one could make the
argument that our current release structure works against their efforts.

All that said, I do see benefits to the current model as well, and I am still
playing around with ideas to see if I just need to switch to new major
versions sooner.  Maybe with FreeBSD 10 we should just follow the OS X model
where major versions are actually minor versions instead. :)  (So FreeBSD 10
would be 10.0, 11 be 10.1, etc.)  People would certainly treat 10.0.1 and
10.0.2 as service packs at that point. :)

Given that the merge from 6 to 7 and 7 to 8 has been far simpler than
previous major versions, some of the trepidation from vendors about frequent
releases may in fact be more of a perception problem that something like 10.x.y
(or even 9.x.y?) could resolve.

-- 
John Baldwin