Robert Godfrey wrote:
2009/12/22 Rafael Schloming <[email protected]>
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
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.
This is actually what I meant. I agree we don't want svn revs in non
development release builds.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
