FreeBSD 6.0 and onwards

[Yuval Levy]

> We are still debating the exact time line, but it will fall somewhere
> between doing a new -STABLE branch every 12-18 months, and doing point
> releases every 4-6 months.

Hi all,

First thank you all for the tremendous effort and passion that you put into
FreeBSD. You guys are doing a great job!

As potential user I have been following your project from the sideline for a
year and decided to migrate from Red Hat Linux to FreeBSD when 5.x becomes
production grade. It will happen soon.

I am a small business and a migration is big headache; a drain on ressources
and time; unnecessary risk. The least I have to migrate, the better. This
conservative attitude conflicts with the progressive nature of technology
(and my own personal attitude). IMHO FreeBSD has good tools (CVS) and
excellent management processes to deal with the conflict. This was the most
important factor to my decision.

Not all migrations are bad: While I prefer to avoid big disruptive changes
(such as from 4.x to 5.x), I appreciate progressive, smooth, incremental
evolution through many little steps. Without knowing the details a change
from 5.x to 6.x sounds like disruption to me. Disrupting too often will turn
users like me away.

As a business I need predictability. I love the idea expressed by Scott
earlier of regular, frequent releases. I'd go one step further: Rather than
declaring the CURRENT branch STABLE and open a new CURRENT branch, I would
suggest to let both branches grow indefinitely with STABLE playing catch-up
on CURRENT. All changes (including major changes such as API) implemented
incrementally rather than disruptively and with a painless upgrade path from
one STABLE version to the next as the recommended way of keeping production
environments alive and secure.

As a naming convention I'd suggest STABLE-yyyyxx (where yyyy is the year and
xx is an incremental counter reset at the beginning of each year) and
CURRENT-yyyyxx.

Upgrading is of critical importance. My wish is for and automated upgrade
path from one STABLE release to the next that can be applied remotely.
Upgrading from STABLE-200401 (4.10) to the next STABLE-200402 (5.3) should
not be more difficult than upgrading from STABLE-200302 (4.9) to
STABLE-200401(4.10). If it is, maybe it is worth to split the new features
over several releases and increase release frequency - a decision for the
release engineering team. As long as the upgrade path is easy and tested, I
would not mind even a monthly release schedule (meaning that there are less
changes between releases).

A higher release frequency should not mean more work for the security team.
As a rule, only the latest STABLE and CURRENT releases should be supported
with patches. The standard recommendation would be "upgrade to the latest
STABLE" and patch on from there if necessary. Only in exceptional cases a
STABLE release should be declared "milestone" and supported by the security
team beyond the next STABLE release for as long as deemed necessary - a
negotiated decision between the security team and the project leader based
on community input, technological progress and available ressources.

In terms of development, new/changed components would start their life on
the CURRENT branch as today. Once the component is ready for prime time, it
is ported to the STABLE branch and released with the next regular release.

>From my (limited) user perspective and measured by the tangible results, the
current CVS tools seem more than adequate. If it ain't broke, don't fix it!
Your project is probably the best managed operating system development in
the world and you have all reason to be proud of your achievements.

Honestly, as a user I don't care much what tool you use to keep track of
changes as long as the tools delivers. It is like a car: drive me from A to
B and I'll be happy, no matter what make or model it is. What I do care
about is the quality of the end product and you guys provide a top class
product with the tools at hand!

Thanks again for the good job!
Yuval Levy