Product versioning and X.Y.Z bumping (was: Re: Cyrus 2.4.1)

[Jeroen van Meeuwen (Kolab Systems)]

Bron Gondwana wrote:
> On Sun, Oct 17, 2010 at 08:26:49PM -0400, Wesley Craig wrote:
> > On 17 Oct 2010, at 06:53, Jeroen van Meeuwen (Kolab Systems) wrote:
> > > I'm in favor to have (in our current X.Y.Z versioning schema) Z be
> > > bumped with bug-fixes only. If we keep it to bug-fixes only, this
> > > means we can rapidly release the fixes to the community.
> > 
> > I'm definitely in favor of that kind of release discipline.  We've had
> > cases where untested features were released along side critical security
> > fixes.  Pre-defining the branches as above would solve that problem
> > while providing at least enough roadmap for viewers at home to follow
> > along.
> 
> That sounds good to me too.  Ken, Dave and I were talking about making
> another major release in January - so we'll just do bugfixes and security
> fixes into the "stable" releases until then.
> 

Let's try and stick to some common terminology - if everyone understands 
something different for "major" and "minor" that doesn't help; I'm just 
thinking out loud here, based on some past experiences;

In a X.Y.Z product versioning schema, X is Major, Y is Minor, Z is Teeny 
(a.k.a. patch-level, a.k.a. z-stream, a.k.a. Minor.Minor).

Let me try and describe some semantics on when a certain X, Y or Z *must* be 
bumped for any of those particular reasons;

Z (Teeny) is typically bumped regularly, and within the same, stable X.Y 
"series" only contains bug-fixes. The more a stable branch matures, obviously, 
the less bug-fixes go in, the less frequent releases are being made. However, 
the Teeny bumping using this restriction of what can go into a teeny bump then 
also says;

- testing is required for the (supposedly) fixed bugs only (including security 
fixes which essentially are bugs),
- no feature enhancements make it into an existing X.Y stable branch, and no 
new features may disrupt the use or X.Y series releases in production,
- the goal is to let the users/admins/consumers be able to "blindly" update 
their way through Teeny releases within a stable Major.Minor series,
- rapid release cycle (one bugfix per teeny release is not unsustainable).

Y (Minor) is typically bumped for feature enhancements. These new features may 
require additional configuration, or some type of manual intervention may be 
required / desirable when upgrading from X.Y to X.(Y+1). However, the former 
notwithstanding, a minor bump typically allows for a pretty smooth upgrade 
path. Meaning, no "legacy" form or operations may be rendered invalid, such 
as; "no database formats supported in 2.3 can be dropped for a 2.4 release", 
no features can be dropped, and no functional changes of any significant 
impact to architecture / infrastructure can be required (example: Do not 
rewrite murder in ways impacting infrastructure topology and so forth).

X (Major) is typically where you abandon a form of compatibility operations, 
and have the opportunity to refactor the lot and break everything down before 
you build it back up again. This includes (potentially) dropping functionality 
(take a step backwards in order to then move forward). There's semantics 
attached to a Major bump;

- There may be no upgrade path without manual conversion or any other type of 
intervention,
- The manual conversion may or may not be aided given a set of utilities, 
which may or may not be available external to the Cyrus IMAP release tarballs, 
and which may or may not be supported to the same extent as the actual program 
code (that said, imapsync your way through this upgrade),
- Topology changes may be required,
- There may or may not be a downgrade path back to the previous major version 
you know worked.

Let me know what you think, we could make this a wiki article of sorts.

Kind regards,

-- 
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08