cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noa Resare <...@spotify.com>
Subject Re: [DISCUSS] adopt semantic versioning for cloudstack?
Date Thu, 10 Jan 2013 21:07:58 GMT
That's great. I'm sorry that I did not do a better job looking for previous
discussion on the matter. Oh well.

/n


On Thu, Jan 10, 2013 at 9:47 PM, Chiradeep Vittal <
Chiradeep.Vittal@citrix.com> wrote:

>
>
> On 1/10/13 12:26 PM, "Noa Resare" <noa@spotify.com> wrote:
>
> >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
>
> I think we already do adopt semver.
> See this discussion
> http://markmail.org/thread/ltnzndyxxkik577x
> And this
> http://markmail.org/thread/adg4wdj27zfw2wa6
>
> But the alpha / beta tags were not discussed.
> We did have rc tags after rounds of QA for 4.0
>
>


-- 
Engineering Experience, Infrastructure tribe, Spotify

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