Next stable version of Samba.

[Kevin Colby]

Not numbering the branches is fine, but then we cannot send out
documentation that refers to them as such.  This goes not just
for TNG, but any "unreleased" versions, as the "2.0.8" vs. "2.2"
points out.

	- Kevin Colby
	  kevinc at grainsystems.com


Gregory Leblanc wrote:
> 
> > -----Original Message-----
> > From: Kevin Colby [mailto:kevinc at grainsystems.com]
> > Sent: Friday, May 19, 2000 2:56 PM
> > To: Multiple recipients of list SAMBA-NTDOM
> > Subject: Re: Next stable version of Samba.
> >
> > No, my point was that if TNG is assigned to 4.0, and TNG
> > ends up being superceded by a superior branch prior
> > to its official release, that next branch could be given
> > "5.0" anyway.  The fact that "4.0" was never an officially
> > supported release would be irrelevant.  Any documentation
> > referring to "4.0" would still be valid.
> >
> > If you don't do this, then either TNG cannot ever be given
> > numbers in the main release schedule prior to "official"
> > support, or you will again have this issue of documentation
> > that refers to a nonexistant release.
> >
> > Comments?
> > (I hope someone is still reading this thread.)
> [snip]
> 
> Yep, still reading.  Personally, I don't think that WAY WAY WAY out
> alpha/beta code should be given release numbers, since it may or may not
> keep that schedule.  I'd call the HEAD code HEAD, and the TNG code TNG.  If
> you want to get into multiple revision numbers, then I'd make it follow the
> guidelines in the Software Release HOWTO.  Now that I think about it some
> more, since Samba tends to have multiple development branches, it doesn't
> make a lot of sense to number any of them, except occasionally, like the
> change that Jeremy proposed.  Depending on how confident the Samba Team is
> in the stability, it might be worth a few 2.1.x releases, with a fixed
> feature set, to ensure stability, leading up to a 2.2.x release, which would
> begin another stable branch like 2.0.x was.
>         Greg