cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noa Resare <>
Subject [DISCUSS] adopt semantic versioning for cloudstack?
Date Thu, 10 Jan 2013 20:26:04 GMT
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


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.



Engineering Experience, Infrastructure tribe, Spotify

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message