Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Jun 2000 13:18:59 -0600
From:      Brett Glass <brett@lariat.org>
To:        Brooks Davis <brooks@one-eyed-alien.net>, Francisco Reyes <fran@reyes.somos.net>
Cc:        FreeBSd Chat list <chat@FreeBSD.ORG>
Subject:   Re: Why can't upgrades be simpler?
Message-ID:  <4.3.2.7.2.20000627131107.0449d500@localhost>
In-Reply-To: <20000626232045.A17065@orion.ac.hmc.edu>
References:  <200006270352.XAA29208@sanson.reyes.somos.net> <200006270352.XAA29208@sanson.reyes.somos.net>

next in thread | previous in thread | raw e-mail | index | archive | help
At 12:20 AM 6/27/2000, Brooks Davis wrote:

>I think the problem is likely one of perception.  One might think that
>there is a logical progression of little steps as follows:
>
>3.0 -> 3.1 -> ... -> 3.4 -> 4.0
>
>The problem is that it's actually more like this:
>
>3.0 -> 3.1 -> ... -> 3.4 -> 3.5
>   \
>    \
>     \
>      -------------> 4.0
>
>What you have is two diverting streams of development starting the
>day the previous .0 release ships[0].  While many changes are merged
>back to the previous branch (or sometimes even further[1]), there are
>inevtiably things which are simply too major to merge into -STABLE.

This is one of the things about the FreeBSD development methodology
with which I (and others!) have long taken issue. Since ".0" versions
are usually described as "experimental," and often have glitches
that make it unwise to deploy them in production environments, the
branching should occur later. Instead of creating a new (N+1).0 branch
as soon as N.0 ships, one should wait for branch N to achieve full
production quality. Thus, (N+1).0 should probably start with the
code from version N.2. The result would look like this:

3.0 -> 3.1 -> 3.2 -> ... -> 3.4 -> 3.5 -> ... -> 3.8
               \
                \
                 \
                  ---------------> 4.0

This would ensure that new versions would be built on a firmer
foundation and that more effort went into maintaining rock-solid
versions of the OS while new branches were perfected. It would
also reduce the effort invested in backporting and would shorten 
the period of time for which a previous version needed to be 
maintained.

--Brett



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.3.2.7.2.20000627131107.0449d500>