Schedule for releases

Garrett Cooper yanegomi at
Thu Dec 23 19:36:09 UTC 2010

On Dec 23, 2010, at 1:37 AM, Giorgos Keramidas <keramida at> wrote:

> On Wed, 22 Dec 2010 09:42:26 -0500, John Baldwin <jhb at> wrote:
>> On Wednesday, December 22, 2010 7:38:34 am Ulrich Spörlein wrote:
>>> I think this is the core "problem". Statistics[1] show, that most
>>> developers run some form of -CURRENT and also have some machines
>>> running the latest -STABLE tree. So, naturally, no-one is too
>>> thrilled about testing stuff for the pre-latest -STABLE tree.
>>> We should not try to have two stable branches overlap for that
>>> long. We are spreading our resources too thin here.
>>> CURRENT+STABLE makes sense, always. CURRENT+STABLE+STABLE might be
>>> nice for vendors, but in the end it's the developers doing the work,
>>> and they mostly only care about the one of the STABLES. We should not
>>> delude ourselves into thinking we can easily support two STABLE
>>> branches, that's just not happening.
>> Actually, CURRENT+STABLE+STABLE doesn't really work for the vendors
>> either versus a CURRENT+STABLE where STABLE branches were created less
>> often and lasted longer.
> Exactly!  My intuition says that vendors don't really care if there are
> two, three, or any number or 'old stable' branches.  All they care is
> that the stable branch they just baselined their source tree on will
> live long enough for their product to ship at least a couple of GA
> versions.
> I've worked at companies where we built products on Solaris 8, for
> example, long after the GA of Solaris 10.  The fact that we had to jump
> forward across two major versions was slightly painful and required a
> non-negligible amount of manpower to pull it off.  The fact that Solaris
> 9 was also 'supported' never really played much of a role in the
> decision to move to the latest release version.  It was always a
> feature-based decision and not a time-based one.

For some groups, they are not dev resource limited, but QA resource limited, so getting all of the core OS changes qualified and into a set of mature products can be a real chore. This is one of the pain points for my group.

More information about the freebsd-arch mailing list