Benefits of multiple release branches (Was: Re: Upcoming Releases Schedule...)

[Dylan Cochran]

On Mon, Sep 22, 2008 at 5:37 PM, Doug Barton <dougb at freebsd.org> wrote:
> Dylan Cochran wrote:
>> One of the biggest (and most prominent, though not obviously so)
>> issues is the lack of concurrency with regards to releases. With the
>> default system, having multiple freebsd releases side by side (both
>> different versions, and different architectures) is infeasible. This
>> makes the choice more critical, while hindering flexibility. The
>> necessity of long support schedules is one of the symptoms.
>
> While on the one hand I can understand the users' frustration on this
> point, IMO having at least 2 release branches is necessary. We are
> trying to walk the fine line between pleasing those who want new
> features (including new drivers), better performance, etc. that a newer
> release branch offers (in this case 7.x) and those that want long-term
> API stability, and other forms of stability that an "established"
> release offers. The only practical way to accomplish both of those goals
> is with 2 release branches.

I agree completely. My point is that as of right now, there is a large
degree of collisions that take place, that prevent an install of
6.3-RELEASE and 7.0-RELEASE from existing at the same time on the same
drive, and being trivial to switch between the two if need be. Same as
with i386/amd64.

This is an artificial construct, and doesn't /have/ to continue
existing. Which imo, will be far more useful then expecting a large
amount of time expended to dead-end branches of code that are well
past their expiration date, and begin suffering from massive bitrot.

At the very least, it will make the default system more robust by
moving the majority of the upgrade procedure from being /replacements/
of files, to creating new files coupled with an atomic activation
'switch'.

Please don't misinterpret my ideas as being supporting his viewpoint,
merely pointing out a perspective to the problem which hasn't been
mentioned.