Ok, I get it now, and I agree. Thanks. -Steve
> -----Original Message----- > From: Rafael Schloming [mailto:[email protected]] > Sent: Tuesday, December 22, 2009 4:28 PM > To: [email protected] > Subject: Re: Release numbering suggestion > > > Steve Huston wrote: > >> -----Original Message----- > >> From: Riggs, Rob [mailto:[email protected]] > >>> -----Original Message----- > >>> From: Steve Huston [mailto:[email protected]] > >>> Sent: Tuesday, December 22, 2009 1:03 PM > >>> To: [email protected]; [email protected] > >>> Subject: RE: Release numbering suggestion > >>> > >>>> -----Original Message----- > >>>> From: Carl Trieloff [mailto:[email protected]] > >>>> 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:[email protected]] > >> > >> On Tue, Dec 22, 2009 at 8:03 PM, Steve Huston > >> <[email protected]> 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 > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
