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