On 2016-03-18 15:25 -0700, Hal Murray wrote: > I think I have figured out part of the disconnect on some of the recent > discussion. > > There are two types of releases. I'll call them "big" and "little". Does > anybody have suggestions for better terms? > > A little release is no big deal. Every two weeks would be fine. It's just a > useful handle on the state of our repository. > > When I hear the word "release", my immediate reaction is to think of a big > release. That's something to be well tested, preferably by users rather than > just insiders, and something that we will support for a while.
Depending on its use most software uses the version numbers to denote how big the changes are. For example a.b.c. if 'a' (major) changes then you can expect zero compatibility. 'b' says it should work with the previous release but there may be issues. 'c' is a minor release and should not cause any problems. Some software uses a 4th 'd' to denote trivial changes. These are sometimes incremented per commit. I have always done releases when the software is at its most stable. Testing is used to decide this but the other major point of data is how many commits are in that release. You don't want to stack too many commits in a release as it becomes difficult to debug issues. Asking users to bisect is a lot hardware than having users hit an issue early on in the release cycle where we can solve it by only looking at a small set of commits. Plenty of users will update for the sake of updating. For NTP some will wait months or even years to see if any issues are reported before upgrading. Personally I think we should just release whatever version happens to be the most stable even if there are only a handful of commits since the last release. Amar. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
