Robert Elz <kre%munnari.OZ.AU@localhost> writes: > What I am thinking for this, is that we create 3 segment version numbers, > N.M.P where "N.M" is the netbsd release the shell started at (so the > NetBSD 7.0 shell would have had N=7 and M=0 had this scheme existed when > it was released. P is to be a patchlevel counter that gets incremented > whenever there are changes made that are significant enough to warrant > calling it a new version - and certainly every time a new vresion is > released to pkgsrc). Just like NetBSD version numbers, M==99 implies > "current" on he way to version N+1. Note that P in the shell version > numbering would have no relationship at all with the third value in > NetBSD version numbers, so NetBSD 7.0.1 7.0.2 ... would all just have a > "7.0.P" shell version number, with whatever value is appropriate for P > (possibly all just 0). > > For now, I am using 7.99.1 as my version number - as I am doing all of > this to the NetBSD current (7.99) shell, and 7.99.0 would be the shell > that is there immediately before this version number shceme is implemented > (and all previous versions... there have been many recently.) I find using 7.99.X awkward, as that's a version that means something for the kernel (and userland more or less), and this is really something quite different. I'd be tempted to call in 1.0.0 arbitrarily, and bump micro on bugfixes (or just prior to export of a new portable version), minor on feature additions, and major on significant compat breaks (perhaps never). That will keep people from inferring things that aren't true.
Attachment:
signature.asc
Description: PGP signature