Re: Identifying the NetBSD shell

[matthew sporleder <msporleder%gmail.com@localhost>]

On Mon, Mar 21, 2016 at 2:14 PM, Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
>
> 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.

I think the responses here have shown that you should just use your
best judgement and stick with it.  :)