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
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
