Simon Burge <simonb@netbsd.org> writes:
> Here's what __NetBSD_Version__ would be defined as:

I think i've thought about this a bit more since last it came up...

>  *      #define __NetBSD_Version__ MMmmrrppRl
>  *
>  *      M = major version
>  *      m = minor version
>  *      r = release ["",A-Z but numeric]
>  *      p = patchlevel
>  *      R = release status (0 pre release, 1 released)
>  *      l = (pre)release level (1 for alpha, 2 for beta, ...)

There's also the issue of what to call the head of the release branch,
i.e. what do you call post-1.4 1.4-branch, before 1.4.1 happens, etc.

I suppose you could accomodate that via R == 2, but that doesn't seem
to fit so well, to my eyes.  I think it'd be better to have something
akin to -current's lettering, so that you could note progression on
the release branch over time.  (We also need a name for these
post-release source versions...  This actually causes a bit of a
problem, if you have 1.4.0A being different than 1.4A...  maybe the
right name includes a teeny version, i.e. 1.4.0.1, 1.4.0.2, etc.)

Over time, i'm also getting less keen on the "alpha," "beta," and
"release" designations for release branch builds, because they
basically _require_ people go back and re-run (at least parts of)
builds before the final release can be declared final.  A "build
number" approach might be slightly more sane.


At the very least, we _need_ a way to solve the issue of how to number
and name the head of the release branch.  This is a real, existing
need, since we provide those sources via both ftp and anon-CVS.  I
suggest that we figure out a sane way to solve that problem (and any
others we think are worth solving) before any of this is actually put
into the source tree and set in something akin to stone...

-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.