+1 big fan of SemVer. From the POV of having written automated patch management software, having to figure out each package's versioning to determine if it's the latest version or not is a PIA.
Making it readable for humans is nice, but when somebody has a farm of 1000s of CS hosts... John On Sep 12, 2012, at 3:49 AM, Noah Slater <nsla...@tumbolia.org<mailto:nsla...@tumbolia.org>> wrote: Agreed. My I suggest we use semantic versioning: http://semver.org/ (As an aside, "-rc" suffixes are fine for temporary artefacts being provided for the connivence of users, as long as they are clearly marked out that way. But you cannot vote on them. To put a release candidate up for a vote you will have to remove the "-rc" suffix first, because once the vote is underway, you cannot change the filenames, or anything else like that.) On Wed, Sep 12, 2012 at 7:01 AM, David Nalley <da...@gnsa.us<mailto:da...@gnsa.us>> wrote: On Wed, Sep 12, 2012 at 1:53 AM, Pradeep Soundararajan <pradeep.soundarara...@citrix.com<mailto:pradeep.soundarara...@citrix.com>> wrote: This is my view. I feel it is not necessary to append the build number and rc tag with the pre-release build. In CloudPlatform for every pre-release we are following 3.0.4-1, 3.0.4-2 etc. I think this denotes RC build. 3.0.4-0.<buildnumber> denotes normal build. Thanks, Pradeep.S It should be clear to anyone who stumbles across such releases that they are not official, sanctioned releases, and if we don't indicate that in the name and merely increment the release we create the opportunity for tremendous confusion. (e.g. is the 3.0.4-1 I downloaded from people.a.o the actual source? --David -- NS Stratosec<http://stratosec.co> - Secure Infrastructure as a Service o: 415.315.9385 @johnlkinsella<http://twitter.com/johnlkinsella>
