> 
> 
> >HOWEVER, I will say this: the next release is likely to be worth
> >it. We'll have the bus_dma stuff fixed (which will fix bounce buffer
> >issues now and forever on all architectures), probably real PCMCIA
> >support, probably real ATAPI support, far improved VM, etc., etc.
> 
> Would you call these changes big enough to warrant a 2.0 instead of
> a 1.3?
> 

My opinion:

We should have changed to Version 2 when the system calling methodology
changed back before 1.2.  

>From what I'm hearing, there have been enough radical changes that
version 1 executables will not work reliably under 1.2D.  If this is the
case, then there is absolutely no excuse to NOT update to version 2.

My personal take on this (having done CM now for about 20 years):

1.  When the interface to a system changes radically, the major number
should be bumped.  The minor number should be reset to 0.

2.  When more than 50% of the code in a system has been changed, the
major number should be bumped EXCEPT if the minor number is 0.  This
takes into account the case where a recent interface change drives a
large code churn.

3.  There should be a target list of changes for each release.  When
those changes are accomplished, the minor number should be bumped unless
the minor number was reset to 0 by 1 or 2 (above).  The target list
should also have a target date (six months is a good consensus
timeframe, from what I've heard). 

NOTE:  If the list only has one item on it, but a bunch of other
projects have been started, then when that single item is ready to roll,
everyone has to be ready to either get it right or get it out.

4.  Once the target list is complete, all changes in progress are
brought to closure and the system is Alpha released.  The Alpha baseline
is established.  This means either backing out the work in progress or
bringing the work to a state where it is working or will not impact
performance.

5.  The bugs from the Alpha test cycle are documented and analyzed.  If
there are no Class A or Class B problems (A being "causes damage to
equipment or files" and B being "causes reproducable system halts and
panics") the code should be promoted to Beta.  If there are, these
problems are addressed.  The Alpha is then re-released.  All SPR driven 
changes are made to the Alpha Baseline code and the -current code.

6.  Once the Beta has been released, a firm release date is established.
For most of the Govt project I've worked on, that is 28 days out.  If no
new Class A or Class B SPRs are received, the code is released on the
release date.  If there are Class A or Class B SPRs, the changes are
made.  The release date does not slip.  For us, a 14 day lead should be
plenty.

7.  If the release date cannot be met, a new Beta is released and a new
release date is established.

The advantage of this is that there are a few driving upgrades that
force new releases.  As an example, we could have established a short
list of "2.0 candidate targets."  which could have included "bounce
buffer support" and "working 100MB/s drivers for all existing network
cards."

The logistics for this are daunting, but are workable.  We are already
working using good CM practices, our testing is good, and the source
code baseline could literally happen almost anytime.

The trick, then, is to find someone willing to do the Release
Engineering.  It's a shame we don't know anyone with years of experience
doing this....

Now for the schedule in real terms:

Day 0 - The list of existing "work in progress" and "need to fix"
problems is culled for the next release.

Day 20 - The list is agreed upon; if anyone disagrees with the
feasability of an item for the releas in 5 months, it is defered.

100 days pass for people to work on their projects.  This should be
enough to at least get to the point that you know whether you will make
the deadline.

Day 120 - The release candidate is checked for completion of the list.
The list is reviewed for possible deletions.  Work continues.

Day 150 - The release candidate is checked.  This is the "drop dead" for
the projects in work.  Everything that is working stays, everything else
is either removed or neutered.  This is the Alpha release.  At this
point, the -current tree is baselined, as is.  Work on -current
continues while the Alpha and Beta trees are used strictly for Problem
reports.  Yes, this involves making the changes twice; once in the Alpha
tree and once in -current.

Day 165 - The Beta is released.  Changes to the Alpha source tree are
included and the Beta tree is baselined.

Day 180 - The release is cut and the next version list is started,  Day
0 is today for release +.1.

Of course, the number of days will be negotiable; it just isn't
something we need to drag on for months at a time.  The 1.2 beta lasted
for (what seemed like) six months.  That is too long.

-- 
Dave Burgess                   Network Engineer - Nebraska On-Ramp, Inc.
*bsd FAQ Maintainer / SysAdmin for the NetBSD system in my spare bedroom
"Just because something is stupid doesn't mean there isn't someone that 
doesn't want to do it...."