VERSION string, support tangle
Mark Atwood
fallenpegasus at gmail.com
Tue Jun 14 00:00:50 UTC 2016
Hi!
Regarding the version string
While we are at 0.9.*, there isn't a need to distinguish pre-release-under-
development 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.
We will make no support or backward compatibility committments until 1.0.*
Once we go 1.*, then we will need a policy. Who has more experience with
the packagers. What do packaging maintainers like the best?
..m
On Mon, Jun 6, 2016 at 11:02 PM Hal Murray <hmurray at megapathdsl.net> wrote:
>
> We had a discussion several months ago, but I don't think we actually
> decided
> what to do.
>
> The current scheme is broken because I can't easily tell a pre-release
> in-development version from the released version.
>
> I know of two ways to fix that. One is to put a suffix on the in-progress
> versions. So instead of 0.9.4 we would have something like 0.9.4x Another
> approach is to use the odd/even numbers: even are releases, odd are
> development.
>
> I vote for odd/even.
>
> ------
>
> We also have to leave room in the version number space for patching
> released
> versions.
>
> That gets back to what is a release and what does support mean? I think we
> want big releases and little ones. What are the right words for big and
> little?
>
> Big releases are supported for a while. A while is ballpark of a year.
> Support means we provide security fixes and possibly fixes to other bugs
> without reasonable work arounds. In particular, we try to avoid user
> visible
> changes.
>
> There may be long term support for selected big releases, say 5 years. The
> idea is to support distros that provide long term support without spending
> too much effort maintaining versions that aren't used.
>
> I think that means that a big release should be bumping the VERSION string
> twice, For example, from 1.5.13 to 1.6.0, then adding the tag, then bumping
> it again to 1.7.0
>
>
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> devel mailing list
> devel at ntpsec.org
> http://lists.ntpsec.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ntpsec.org/pipermail/devel/attachments/20160614/f3189768/attachment.html>
More information about the devel
mailing list