On Mon, Mar 21, 2016 at 2:14 PM, Greg Troxel <[email protected]> wrote: > > Robert Elz <[email protected]> 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.
I think the responses here have shown that you should just use your best judgement and stick with it. :)
