Current stable tag slip status

[Bill Hacker]

Ed wrote:

On Monday 21 March 2005 02:29, Matthew Dillon wrote:

   After the stable tag is slipped we will begin release engineering for
   a release prior to USENIX (which I will be at, BTW).  I am going to
   call this release 1.5 oweing to the fact that the big ticket journaling
   item isn't done.  The release date will be in early April.
   Then, tentatively, since so much progress is being made, the 2.0
release will likely occur in September.


I'd suggest to use lower release numbers.
I think it's better to call 1.1 the April release, and then 1.2 and so.
The fact is that if you jump from major numbers (1.x to 2.x) every year, the 
first DF release with all the cool features will have a big number like 7 or 
8. And I don't think it's a good idea. Think at Mandrake 10, RedHat 10, 
Solaris 10 and so on.

Also, if you follow my advice you could be able to make a big step for a 
particular milestone, for example jumping from 2.3 to 3.0. That would not be 
possible if you already jump by 0.5 every 6 months.

I'm sure to branded a heretic here, but the 'numbers game'
is one of the less-attractive features of software.
How about a system such as:

STABLE releases = DFSMMMYY

- *never* a day, no suffix for major 'milestone' releases
- *2 digit* suffix for up to 100 per-month incremental changes.
i.e. DFSAPR05,  DFSAPR05.08

CURRENT releases = DFCMMMDDYY
- *always* a day
- *1 digit* suffix for up to ten per day incremental changes/patches
i.e.  DFCAPR0205, DFCAPR0205.01, DFCAPR0305.1, DFCAPR0305.2

EXPERIMENTAL or testing versions = DFXMMMDDYY.nn
- *always* a day
- 3-digit suffix handles as many as 100 on any given day...
Rationale for including 'DFS', 'DFC', or 'DFX' is immediate
and easy ID from uname -a or whatever.
I've seen too many threads (elsewhere) and even a
few here where information sought and
advice given were not in sync 'coz the parties were
not talking about the same code base.
YMMV.

Bill