Date: Sun, 23 Apr 1995 16:44:39 +1000 From: Stephen McKay <syssgm@devetir.qld.gov.au> To: "Jordan K. Hubbard" <jkh@freefall.cdrom.com> Cc: hackers@FreeBSD.org, syssgm@devetir.qld.gov.au Subject: Re: Release stability (fwd) Message-ID: <199504230644.QAA11076@orion.devetir.qld.gov.au>
next in thread | raw e-mail | index | archive | help
"Jordan K. Hubbard" <jkh@freefall.cdrom.com> wrote: >> In the old DEC world there was a three piece cycle that was followed >> many times. A feature release followed by a robustness release. There >> was also a performance release that followed the robustness release. > >Yes, I think that a new/stable/fast cycle of 3 has a lot to be said >for it. What would people say to us going to the following numbering >scheme in support of this? > ><rel>.<0,1,2[,3..]>[.<snap>] I had to join in just to clear up a minor point for some of us who treat version numbers as something other than arbitrary (hopefully unique*) tags. Are you implying that 3.0 will roll out simply because 2.n used up its number range, or will 3.0 have to be, say, the first SMP edition, or the first multi-platform edition? It seems much more logical to me for the system to be: <rel>.<sub>.<polish>.<snap> Thus, <rel> corresponds to truly large changes such as switching from net/2 to 4.4 (or the others I mentioned above), which you expect to offer great future gains, but short-term instability. <sub> corresponds to adding new but not world-shaking features, ie normal developmental progress. <polish> is fixing and polishing of the more recent features, hopefully without introducing any more features. <snap> is available for alpha, beta, gamma testing, or the existing snap system, whichever makes more sense to everyone. The major drama with this proposal is the requirement to branch the source tree when some people want to add major goodies while the rest are still polishing. Other posts implied that this was difficult, and that not enough people are available to ensure that fixes make it into both trees. It seems highly unlikely that people could simply hold off adding goodies because of the current position in the release cycle. Ok, I've bored a hundred people, but I'm just wishing that the numbering could be strictly hierachical with major change down to minor change. No trailing RELEASE, ALPHA or other difficult additions please. :-) Stephen. * Just look at Microsoft, who don't bother to update their release numbers for all changes! DISCLAIMER: I use this sort of numbering for my own stuff, but no one else seems to care what I use as long as the numbers increase! Final PS: I used 1.1 for a year with excellent stability right up until a SCSI tape bug bit-sprayed my hard disk. Now I'm having a very good time with 2.0R (modulo a small VM problem when accessing raw disk partitions). I think the people who complained about 1.1 and 2.0R are being far too harsh. Both are much better than the System V stuff I used to have!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504230644.QAA11076>