I can definitely agree with all of that. Still think it looks goofy skipping minors though ;)
I don't particularly like that if someone goes off and does their own release off trunk based on our trunk version (eg Fedora) they will thus have a higher (if odd looking thanks to SVN rev) release version number than we do (to those users not looking at the repo, just the downloads). Though I guess it would mean we wouldnt get users of said releases coming to our user list like presently saying they were using '0.5' when in fact they aren't really. Also seems like it will make for confusion/annoyance if we ever wanted to do our own 0.X.Y release since trunk would already have gone up to 0.<X+1>.<rev>...though I guess branches and merges solve that one easily enough. OK I have apparently talked myself around. Other than thinking it looks goofy I don't have any objections of substance ;-) Genuine question, who does version this way? I can't think of any I've seen like it. Robbie > -----Original Message----- > From: Robert Godfrey > > 2009/12/22 Robbie Gemmell <[email protected]> > > Any takers for x.y.z for releases, with x.y.<svn> for dev? > > There is never a possibility they will clash unless we first do > ~<current > > svn revision> z's per x.y > > > > > I prefer having a clean separation of dev and release with the > invariant > that 0.6.x < 0.7.x < 0.8.x and also 0.6.x < 0.6.y iff x < y. If you > mix up > svn micro releases and real micro releases with the same minor number > you > lose this. if you use the numbers for any sort of dependency driven > packaging tool it'll probably end up favouring dev versions over > release > versions which would be *bad* :-) > > -- Rob > > > > Robbie > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
