<div dir="ltr">Hi!<div><br></div><div>Regarding the version string</div><div><br></div><div>While we are at 0.9.*, there isn't a need to<span style="line-height:1.5"> distinguish pre-release-under-</span>development<span style="line-height:1.5"> and "release".   Our users so far seem to be quite willing to pull from tip, or pull from the most recent tag, depending on what they intend.  The security researchers looking at us also do the same, checking out both tip and latest tag.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">We will make no support or backward compatibility committments until 1.0.*</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Once we go 1.*, then we will need a policy.  Who has more experience with the packagers.  What do packaging maintainers like the best?</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">..m</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5"><br></span></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 6, 2016 at 11:02 PM Hal Murray <<a href="mailto:hmurray@megapathdsl.net">hmurray@megapathdsl.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
We had a discussion several months ago, but I don't think we actually decided<br>
what to do.<br>
<br>
The current scheme is broken because I can't easily tell a pre-release<br>
in-development version from the released version.<br>
<br>
I know of two ways to fix that.  One is to put a suffix on the in-progress<br>
versions.  So instead of 0.9.4 we would have something like 0.9.4x  Another<br>
approach is to use the odd/even numbers: even are releases, odd are<br>
development.<br>
<br>
I vote for odd/even.<br>
<br>
------<br>
<br>
We also have to leave room in the version number space for patching released<br>
versions.<br>
<br>
That gets back to what is a release and what does support mean?  I think we<br>
want big releases and little ones.  What are the right words for big and<br>
little?<br>
<br>
Big releases are supported for a while.  A while is ballpark of a year.<br>
Support means we provide security fixes and possibly fixes to other bugs<br>
without reasonable work arounds.  In particular, we try to avoid user visible<br>
changes.<br>
<br>
There may be long term support for selected big releases, say 5 years.  The<br>
idea is to support distros that provide long term support without spending<br>
too much effort maintaining versions that aren't used.<br>
<br>
I think that means that a big release should be bumping the VERSION string<br>
twice, For example, from 1.5.13 to 1.6.0, then adding the tag, then bumping<br>
it again to 1.7.0<br>
<br>
<br>
<br>
<br>
--<br>
These are my opinions.  I hate spam.<br>
<br>
<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a><br>
<a href="http://lists.ntpsec.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ntpsec.org/mailman/listinfo/devel</a><br>
</blockquote></div>