From owner-freebsd-current  Wed Nov  1 22:11:11 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id WAA16514
          for current-outgoing; Wed, 1 Nov 1995 22:11:11 -0800
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA16504
          ; Wed, 1 Nov 1995 22:11:08 -0800
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id WAA20044; Wed, 1 Nov 1995 22:08:08 -0800
To: Chuck Robey <chuckr@glue.umd.edu>
cc: -Vince- <vince@apollo.COSC.GOV>,
        Ollivier Robert <roberto@keltia.freenix.fr>, julian@ref.tfs.com,
        jc@irbs.com, current@FreeBSD.org, FAQ@FreeBSD.org
Subject: Re: FreeBSD 2.1 update 
In-reply-to: Your message of "Wed, 01 Nov 1995 23:16:53 EST."
             <Pine.SUN.3.91.951101231224.26683A-100000@latte.eng.umd.edu> 
Date: Wed, 01 Nov 1995 22:08:08 -0800
Message-ID: <20042.815292488@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-current@FreeBSD.org
Precedence: bulk

> Maybe that's right, but it's not what I understood to be true.  Understand
> that this stuff is not written in stone, there are no contracts forcing 
> things to happen in any particular manner, but I had the understanding 
> that we were going to be doing a dual-track thing.  The even numbered 

The problem is that the dual-track thing is turning into a LOT of
work, and I don't think that David is entirely amused at the amount of
life he's lost in keeping things in sync..  What will no doubt evolve
is something more "holistic" where we maintain the 2.1 release branch
as long as it seems practical to do so (e.g. as long as it makes sense
to continue releasing bug-fix point releases along it) and beaver away
in 2.2 as the catch-all experiemental branch.  At some stage, I'd hope
that 2.2 would slow down enough to become stable, at which point
(perhaps just short of the point of most ideal stability) maybe we'll
just branch again and let 2.2 become what 2.1 is now, with 2.3
becoming -current.

I don't know though, we could end up doing something entirely
different than this.  This is one of those things that's really
difficult to do advance planning for in a volunteer effort.  Sometimes
we move really fast, other times we slow to a crawl.  Sometimes we fix
something really critical and we'd really like to see it in a release,
other times we break the tree pretty badly for awhile with a new
experimental feature that eventually turns out to be worth the effort
but is a pain in the butt during the transition period.

I do know that we have very finite engineering resources, and we need
to apply them in the most cost-effective manner or we will simply
cease to exist.  Striking a balance between this and what the users
want is the challenge we'll be facing over the next 12 months or so,
and this will effect how the releases are numbered and planned.

					Jordan