Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of noa@spotify.com designates
 209.85.217.176 as permitted sender)
MIME-Version: 1.0
Date: Thu, 10 Jan 2013 21:26:04 +0100
Message-ID: 
 <CANc7MVzFTAkLU=JO-7Qac=Nd_HYnDJjA359544+q6s3Aa1skAw@mail.gmail.com>
Subject: [DISCUSS] adopt semantic versioning for cloudstack?
From: Noa Resare <noa@spotify.com>
To: cloudstack-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=e0cb4efe3178f5267e04d2f4fc63

--e0cb4efe3178f5267e04d2f4fc63
Content-Type: text/plain; charset=ISO-8859-1

I think it is very useful to be able to have some expectations on the
semantics of the releases that software projects releases. I like the
Semantic Versioning Specification(1), and I think it would be useful for us
to adopt it to the extent possible.

I don't know if you are familiar with that specification, but basically it
asserts that conforming software gets released with versions of format
MAJOR.MINOR.PATCHLEVEL and one can have certain expectations from those
releases based on which value has been incremented.

In short, no additional functionality or API changes in PATCHLEVEL
increment releases, only backwards compatible changes in MINOR releases and
MAJOR releases for backwards incompatible changes.

So, my proposal would be to adopt the standard.

The only thing I have noticed so far that we would need to change it the
system where there is voting several different software versions with the
same (final name). I think it would be much more convenient (and also
semver compliant) to release those as x.y.z-rcN and once the voting is
concluded create an x.y.z version that is identical to the last x.y.z-rcN
release. Having the same release with multiple version designators is much
better than having mulitple releases with the same version.

While we're at it I would like to propose another constraint on prerelease
naming that is not part of semver, and that is that pre-releases have names
that sort in lexical order. That way it gets much simpler to work with
packaging.

Example:

5.4.3 to 5.5.0-alpha1 (first WIP release of the 5.5.0 release cycle)
5.5.0-alpha1 to 5.5.0-alpha2
5.5.0-alpha2 to 5.5.0-beta1 (okay, because b is sorted after a)
5.5.0-beta1 to 5.5.0-rc1 (first release candiate, also okay)
5.5.0-rc1 to 5.5.0-rc2
5.5.0-rc2 to 5.5.0 (this is the actual release)

These versions can be transposed into a package version in both rpm and deb
universe using the pattern x.y.z-aN -> x.y.x-0.aN. This strategy will break
if someone decides that 'almost_there' comes after 'rc', so please let's
not do that.

/n

1) http://semver.org

-- 
Engineering Experience, Infrastructure tribe, Spotify

--e0cb4efe3178f5267e04d2f4fc63--