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.vit...@citrix.com> wrote: > > > On 1/10/13 12:26 PM, "Noa Resare" <n...@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
