Product versioning and X.Y.Z bumping (was: Re: Cyrus 2.4.1)
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Mon Oct 18 07:32:33 EDT 2010
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
- 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
- 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.
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
pgp: 9342 BF08
More information about the Cyrus-devel