What is a release?
Amar Takhar
verm at darkbeer.org
Sat Mar 19 03:06:00 UTC 2016
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.
More information about the devel
mailing list