Date: Thu, 23 Dec 2010 10:37:32 +0100 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: John Baldwin <jhb@freebsd.org> Cc: Ulrich =?iso-8859-1?Q?Sp=F6rlein?= <uqs@spoerlein.net>, Oliver Fromme <olli@lurza.secnetix.de>, freebsd-arch@freebsd.org Subject: Re: Schedule for releases Message-ID: <xeiabp4cygmb.fsf@kobe.laptop> In-Reply-To: <201012220942.26579.jhb@freebsd.org> (John Baldwin's message of "Wed, 22 Dec 2010 09:42:26 -0500") References: <DB4D8AC7-25D6-4901-BBF9-77BEB956840B@cederstrand.dk> <201012220852.oBM8q2Qi039123@lurza.secnetix.de> <20101222123834.GN23098@acme.spoerlein.net> <201012220942.26579.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Dec 2010 09:42:26 -0500, John Baldwin <jhb@freebsd.org> wrote: > On Wednesday, December 22, 2010 7:38:34 am Ulrich Sp=F6rlein 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xeiabp4cygmb.fsf>