2009/12/22 Rafael Schloming <rafa...@redhat.com> > Steve Huston wrote: > >> -----Original Message----- >>> From: Riggs, Rob [mailto:rob.ri...@epsilon.com] >>> >>>> -----Original Message----- >>>> From: Steve Huston [mailto:shus...@riverace.com] >>>> Sent: Tuesday, December 22, 2009 1:03 PM >>>> To: cctriel...@redhat.com; dev@qpid.apache.org >>>> Subject: RE: Release numbering suggestion >>>> >>>> -----Original Message----- >>>>> From: Carl Trieloff [mailto:cctriel...@redhat.com] >>>>> One late suggestion to the thread. after release update >>>>> >>>> the trunk to >>> >>>> 0.7. >>>>> >>>> Right, but my point is that this week's 0.7 is not the same as next >>>> week's 0.7. So you still can't really identify what someone >>>> >>> is working >>> >>>> with just by saying 0.7, so what are we really buying with this scheme? >>>> >>> Not much for the developers. Lots for us users. Us users can start >>> making RPM packages of development versions and know immediately whether a >>> dev or stable version is installed. Right now that is not possible. >>> >>> Going forward, you will be working on version 0.7. I create a number of >>> qpid 0.7 RPMs as development progresses to test various features. 0.7 is >>> released. Two months later I check the packages that are installed on my >>> system. RPM tells me qpid 0.7 is installed. Is it development or a released >>> version? >>> >> >> Ok, I see. Thanks. How do you manage multiple variations on 0.7? Is that >> an issue? >> >> -----Original Message----- >>> From: Aidan Skinner [mailto:aidan.skin...@gmail.com] >>> On Tue, Dec 22, 2009 at 8:03 PM, Steve Huston <shus...@riverace.com> >>> wrote: >>> >>> Right, but my point is that this week's 0.7 is not the same as next >>>> week's 0.7. So you still can't really identify what someone >>>> >>> is working >>> >>>> with just by saying 0.7, so what are we really buying with this scheme? >>>> >>> We could stick the svn rev as the micro version for development builds. >>> >>> 0.7.8234324 is a bit ugly but gets the point across. >>> >> >> I agree on both points. >> Is that what users want/need? >> > > I think to put oneself in the user's mindset you need to forget about > branches and JIRA and all that stuff and only think about the version number > that the software reports when you type 'foo --version'. > > Right now that number is confusing to them because they could have their > hands on a build of a random dev version and a build of a released version > of the code, and both would report the same version number. This is true > regardless of whether you bump before or after a release. > > If you bump both before *and* after a release then they at least have some > indication that if the number reported is odd they are getting potentially > incomplete information. I think the ideal would be to bump before and after > the release and also have --version report the svn version number as above. > > --Rafael > > > So, I'm +1 for dev builds being 0.<2x+1>.<svn rev number>, and released builds being 0.<2x>.<meaningful micro version>
Builds directly off trunk should look ugly :-) and it's OK that the version number isn't all that memorable... You do want builds of distinct revisions to have distinct version numbers though. For released builds 0.8.0, 0.8.1 etc makes a lot more sense to me than sticking the svn rev number in the micro version. -- Rob
