You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Andrew Stitcher <as...@redhat.com> on 2009/12/22 16:43:45 UTC
Release numbering suggestion
We currently have a problem distinguishing between the qpid release
numbering for actual releases and release branches and code development
on trunk.
For example before starting the 0.6 release the label 0.5 was ambiguous
- it referred both to the development code on the and the code in the
0.5 release. By that I mean that the code on trunk thought it was 0.5
too and reported that.
I propose that we change the trunk numbering to 0.7 at the point we
branch 0.6 for release.
Then I propose that we change the numbering to 0.8 when we start the
next release process.
Then we would change trunk numbering to 0.9 when branching the next
release etc.
The advantage of this scheme is that it is immediately obvious whether a
given release is development or a released release (odd numbers are dev,
even are release). It also means that the numbering is never shared
between trunk and a branch.
Minor disadvantage: Our releases skip from 0.6 to 0.8 to 0.10 etc.
Comments?
[unless I hear heated opposition by the actual point of release, I will
do this]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Rafael Schloming <ra...@redhat.com>.
Alan Conway wrote:
> On 12/22/2009 10:43 AM, Andrew Stitcher wrote:
>> We currently have a problem distinguishing between the qpid release
>> numbering for actual releases and release branches and code development
>> on trunk.
>>
>> For example before starting the 0.6 release the label 0.5 was ambiguous
>> - it referred both to the development code on the and the code in the
>> 0.5 release. By that I mean that the code on trunk thought it was 0.5
>> too and reported that.
>>
>> I propose that we change the trunk numbering to 0.7 at the point we
>> branch 0.6 for release.
>>
>> Then I propose that we change the numbering to 0.8 when we start the
>> next release process.
>>
>> Then we would change trunk numbering to 0.9 when branching the next
>> release etc.
>
> How about we change the number to 0.7 when we branch 0.6, and leave it
> 0.7 when we release 0.7. There's no ambiguity: 0.7 refers to the code
> that will someday be release 0.7 up to the day it actually becomes 0.7.
This would remove the ambiguity and we should make sure to do this at a
minimum.
>> The advantage of this scheme is that it is immediately obvious whether a
>> given release is development or a released release (odd numbers are dev,
>> even are release). It also means that the numbering is never shared
>> between trunk and a branch.
>
> What's the purpose of a separate version number for in between releases?
>
>> Minor disadvantage: Our releases skip from 0.6 to 0.8 to 0.10 etc.
>>
>> Comments?
>>
>> [unless I hear heated opposition by the actual point of release, I will
>> do this]
>>
>
> Not heated opposition, I'm just not understanding the benefits.
The benefit is being able to easily distinguish between a random
development version of the code that is in-between releases and a
version of the code that is in close proximity to a release (either just
before a release or just after).
Basically we can choose to bump version numbers just before releases,
just after releases, or both.
I think at a minimum we need to always bump just after releases. Other
than that I'm fairly relaxed, although I can see the appeal of bumping
both before and after.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Alan Conway <ac...@redhat.com>.
On 12/22/2009 12:06 PM, Andrew Stitcher wrote:
> On Tue, 2009-12-22 at 11:37 -0500, Alan Conway wrote:
>> ...
>> How about we change the number to 0.7 when we branch 0.6, and leave it 0.7 when
>> we release 0.7. There's no ambiguity: 0.7 refers to the code that will someday
>> be release 0.7 up to the day it actually becomes 0.7.
>
> I could certainly accept that. What I think is wrong is leaving the
> trunk with the old release number until starting the next release
> process.
>
>>
>>>
>>> The advantage of this scheme is that it is immediately obvious whether a
>>> given release is development or a released release (odd numbers are dev,
>>> even are release). It also means that the numbering is never shared
>>> between trunk and a branch.
>>
>> What's the purpose of a separate version number for in between releases?
>
> Well partly it's precisely because it allow you to tell at a glance
> whether a bug report is against a released version of qpid or against a
> devel version of qpid.
>
> I think the major advantage of distinguishing between release/dev
> versions is in bug reporting and scheduling bug fixes.
>
> I have to say that I think these are enough to make me want to do it,
> but not enough that I'm totally attached to the even-odd thing.
>
> Another point is that a number of other projects do distinguish between
> dev and release versions using precisely this model - it's not a proof
> that it's any good for us, but an indication that it's useful for them.
>
OK, sounds reasonable. No objection from me.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Aidan Skinner <ai...@gmail.com>.
On Tue, Dec 22, 2009 at 5:06 PM, Andrew Stitcher <as...@redhat.com> wrote:
> Another point is that a number of other projects do distinguish between
> dev and release versions using precisely this model - it's not a proof
> that it's any good for us, but an indication that it's useful for them.
Yeah, it's really quite handy. I'd be +1 for this, especially if we
moved to full APR/Linux kernel style major.minor.micro
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Release numbering suggestion
Posted by Andrew Stitcher <as...@redhat.com>.
On Tue, 2009-12-22 at 14:38 -0500, Steve Huston wrote:
> ...
> But what's a dev "version"? The only time you can really have a
> meaningful "version" is when it's tagged and set aside. Dev stuff is a
> moving target. Any given number assigned to "dev" today is not the same
> as tomorrow's.
>
The meaningful version comment is true as far as full release version is
concerned, but in that case it is a shorthand for a specific subversion
commit. However it is certainly meaningful to use the first 2 numbers to
indicate which line of development is being run.
> What does it mean to schedule a fix for "dev"?
On the whole all bug fixes should be fixed in dev releases. The only
ones fixed in releases are ones that are fixed during the release
process itself, or are fixed on the release branch.
I would say though that distinguishing dev versions from release version
is more important for us in bug triage to figure what code a bug
reporter is running. It is true that svn revision would also do, but
it's not as descriptive.
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Nuno Santos <ns...@redhat.com>.
On 12/22/2009 04:12 PM, Steve Huston wrote:
>> From: Aidan Skinner [mailto:aidan.skinner@gmail.com]
>> 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?
FWIW, that's the numbering scheme I've been using when building the
qpidc packages for Fedora (which have usually been built off of trunk,
not necessarily off of a released branch). I agree that although
verbose, it gives plenty of useful information at a glance.
Nuno
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Godfrey wrote:
> 2009/12/22 Rafael Schloming <ra...@redhat.com>
>
>> Steve Huston wrote:
>>
>>> -----Original Message-----
>>>> From: Riggs, Rob [mailto:Rob.Riggs@epsilon.com]
>>>>
>>>>> -----Original Message-----
>>>>> From: Steve Huston [mailto:shuston@riverace.com]
>>>>> Sent: Tuesday, December 22, 2009 1:03 PM
>>>>> To: cctrieloff@redhat.com; dev@qpid.apache.org
>>>>> Subject: RE: Release numbering suggestion
>>>>>
>>>>> -----Original Message-----
>>>>>> From: Carl Trieloff [mailto:cctrieloff@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.skinner@gmail.com]
>>>> On Tue, Dec 22, 2009 at 8:03 PM, Steve Huston <sh...@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.
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:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Robbie Gemmell <ro...@gmail.com>.
Ah, should have thought of that one...although 2.6 is all ive ever
used hehe, which is probably why it didnt click ;p
Git is awesome isnt it :)
Robbie
2009/12/23 Andrew Stitcher <as...@redhat.com>:
> On Tue, 2009-12-22 at 23:35 +0000, Robbie Gemmell wrote:
>> ...
>> Genuine question, who does version this way? I can't think of any I've seen
>> like it.
>
> Used to be the Linux kernel did that, with 2.0, 2.2, 2.4, 2.6 being
> release trains and 2.1, 2.3, 2.5 being development. However since 2.6
> was release (a long while ago now) they seem to have been developing
> differently, and no 2.7 has been (or seems likely to be) opened.
> Something to do with the _awesomeness_ of git (obligatory mention
> specially for Rafi).
>
> Andrew
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Release numbering suggestion
Posted by Andrew Stitcher <as...@redhat.com>.
On Tue, 2009-12-22 at 23:35 +0000, Robbie Gemmell wrote:
> ...
> Genuine question, who does version this way? I can't think of any I've seen
> like it.
Used to be the Linux kernel did that, with 2.0, 2.2, 2.4, 2.6 being
release trains and 2.1, 2.3, 2.5 being development. However since 2.6
was release (a long while ago now) they seem to have been developing
differently, and no 2.7 has been (or seems likely to be) opened.
Something to do with the _awesomeness_ of git (obligatory mention
specially for Rafi).
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Release numbering suggestion
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <ro...@gmail.com>
> > 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:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Robert Godfrey <ro...@gmail.com>.
2009/12/22 Robbie Gemmell <ro...@gmail.com>
> I think skipping minors on release versions is icky, but I guess that's
> just
> me hehe.
>
> 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
>
> > -----Original Message-----
> > From: Aidan Skinner [mailto:aidan.skinner@gmail.com]
> > Sent: 22 December 2009 21:42
> > To: dev@qpid.apache.org
> > Subject: Re: Release numbering suggestion
> >
> > On Tue, Dec 22, 2009 at 9:34 PM, Robert Godfrey
> > <ro...@gmail.com> wrote:
> >
> > > So, I'm +1 for dev builds being 0.<2x+1>.<svn rev number>, and
> > released
> > > builds being 0.<2x>.<meaningful micro version>
> >
> > Sounds like a plan to me.
> >
> > - Aidan
> >
> > --
> > Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
> > "A witty saying proves nothing" - Voltaire
> >
> > ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
RE: Release numbering suggestion
Posted by Robbie Gemmell <ro...@gmail.com>.
I think skipping minors on release versions is icky, but I guess that's just
me hehe.
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
Robbie
> -----Original Message-----
> From: Aidan Skinner [mailto:aidan.skinner@gmail.com]
> Sent: 22 December 2009 21:42
> To: dev@qpid.apache.org
> Subject: Re: Release numbering suggestion
>
> On Tue, Dec 22, 2009 at 9:34 PM, Robert Godfrey
> <ro...@gmail.com> wrote:
>
> > So, I'm +1 for dev builds being 0.<2x+1>.<svn rev number>, and
> released
> > builds being 0.<2x>.<meaningful micro version>
>
> Sounds like a plan to me.
>
> - Aidan
>
> --
> Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
> "A witty saying proves nothing" - Voltaire
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Aidan Skinner <ai...@gmail.com>.
On Tue, Dec 22, 2009 at 9:34 PM, Robert Godfrey <ro...@gmail.com> wrote:
> So, I'm +1 for dev builds being 0.<2x+1>.<svn rev number>, and released
> builds being 0.<2x>.<meaningful micro version>
Sounds like a plan to me.
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Robert Godfrey <ro...@gmail.com>.
2009/12/22 Rafael Schloming <ra...@redhat.com>
> Steve Huston wrote:
>
>> -----Original Message-----
>>> From: Riggs, Rob [mailto:Rob.Riggs@epsilon.com]
>>>
>>>> -----Original Message-----
>>>> From: Steve Huston [mailto:shuston@riverace.com]
>>>> Sent: Tuesday, December 22, 2009 1:03 PM
>>>> To: cctrieloff@redhat.com; dev@qpid.apache.org
>>>> Subject: RE: Release numbering suggestion
>>>>
>>>> -----Original Message-----
>>>>> From: Carl Trieloff [mailto:cctrieloff@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.skinner@gmail.com]
>>> On Tue, Dec 22, 2009 at 8:03 PM, Steve Huston <sh...@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
RE: Release numbering suggestion
Posted by Steve Huston <sh...@riverace.com>.
Ok, I get it now, and I agree. Thanks.
-Steve
> -----Original Message-----
> From: Rafael Schloming [mailto:rafaels@redhat.com]
> Sent: Tuesday, December 22, 2009 4:28 PM
> To: dev@qpid.apache.org
> Subject: Re: Release numbering suggestion
>
>
> Steve Huston wrote:
> >> -----Original Message-----
> >> From: Riggs, Rob [mailto:Rob.Riggs@epsilon.com]
> >>> -----Original Message-----
> >>> From: Steve Huston [mailto:shuston@riverace.com]
> >>> Sent: Tuesday, December 22, 2009 1:03 PM
> >>> To: cctrieloff@redhat.com; dev@qpid.apache.org
> >>> Subject: RE: Release numbering suggestion
> >>>
> >>>> -----Original Message-----
> >>>> From: Carl Trieloff [mailto:cctrieloff@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.skinner@gmail.com]
> >>
> >> On Tue, Dec 22, 2009 at 8:03 PM, Steve Huston
> >> <sh...@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-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Rafael Schloming <ra...@redhat.com>.
Steve Huston wrote:
>> -----Original Message-----
>> From: Riggs, Rob [mailto:Rob.Riggs@epsilon.com]
>>> -----Original Message-----
>>> From: Steve Huston [mailto:shuston@riverace.com]
>>> Sent: Tuesday, December 22, 2009 1:03 PM
>>> To: cctrieloff@redhat.com; dev@qpid.apache.org
>>> Subject: RE: Release numbering suggestion
>>>
>>>> -----Original Message-----
>>>> From: Carl Trieloff [mailto:cctrieloff@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.skinner@gmail.com]
>>
>> On Tue, Dec 22, 2009 at 8:03 PM, Steve Huston
>> <sh...@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-subscribe@qpid.apache.org
RE: Release numbering suggestion
Posted by Steve Huston <sh...@riverace.com>.
> -----Original Message-----
> From: Riggs, Rob [mailto:Rob.Riggs@epsilon.com]
> > -----Original Message-----
> > From: Steve Huston [mailto:shuston@riverace.com]
> > Sent: Tuesday, December 22, 2009 1:03 PM
> > To: cctrieloff@redhat.com; dev@qpid.apache.org
> > Subject: RE: Release numbering suggestion
> >
> > > -----Original Message-----
> > > From: Carl Trieloff [mailto:cctrieloff@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.skinner@gmail.com]
>
> On Tue, Dec 22, 2009 at 8:03 PM, Steve Huston
> <sh...@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?
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Release numbering suggestion
Posted by "Riggs, Rob" <Ro...@epsilon.com>.
> -----Original Message-----
> From: Steve Huston [mailto:shuston@riverace.com]
> Sent: Tuesday, December 22, 2009 1:03 PM
> To: cctrieloff@redhat.com; dev@qpid.apache.org
> Subject: RE: Release numbering suggestion
>
> > -----Original Message-----
> > From: Carl Trieloff [mailto:cctrieloff@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?
Rob
This e-mail and files transmitted with it are confidential, and are intended solely for the use of the individual or entity to whom this e-mail is addressed. If you are not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you are not one of the named recipient(s) or otherwise have reason to believe that you received this message in error, please immediately notify sender by e-mail, and destroy the original message. Thank You.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Aidan Skinner <ai...@gmail.com>.
On Tue, Dec 22, 2009 at 8:03 PM, Steve Huston <sh...@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.
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Dec 22, 2009 at 3:03 PM, Steve Huston <sh...@riverace.com> wrote:
>> -----Original Message-----
>> From: Carl Trieloff [mailto:cctrieloff@redhat.com]
>>
>> > But what's a dev "version"? The only time you can really have a
>> > meaningful "version" is when it's tagged and set aside. Dev
>> stuff is a
>> > moving target. Any given number assigned to "dev" today is not the
>> > same as tomorrow's.
>> >
>> > What does it mean to schedule a fix for "dev"?
>> >
>>
>> 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?
I think Rafi's suggestion of having a svn rev attached to the version
could potentially solve this issue.
Btw +1 for Andrews suggestion.
>> Then when we next release we make it 0.8.
>>
>> Thus moving forward all dev code will have odd numbers, and
>> releases will be even 0.6 0.8 0.10 / 1.0 etc.
>
>> Carl.
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Release numbering suggestion
Posted by Steve Huston <sh...@riverace.com>.
> -----Original Message-----
> From: Carl Trieloff [mailto:cctrieloff@redhat.com]
>
> > But what's a dev "version"? The only time you can really have a
> > meaningful "version" is when it's tagged and set aside. Dev
> stuff is a
> > moving target. Any given number assigned to "dev" today is not the
> > same as tomorrow's.
> >
> > What does it mean to schedule a fix for "dev"?
> >
>
> 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?
> Then when we next release we make it 0.8.
>
> Thus moving forward all dev code will have odd numbers, and
> releases will be even 0.6 0.8 0.10 / 1.0 etc.
>
> Carl.
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Carl Trieloff <cc...@redhat.com>.
> But what's a dev "version"? The only time you can really have a
> meaningful "version" is when it's tagged and set aside. Dev stuff is a
> moving target. Any given number assigned to "dev" today is not the same
> as tomorrow's.
>
> What does it mean to schedule a fix for "dev"?
>
One late suggestion to the thread. after release update the trunk to 0.7.
Then when we next release we make it 0.8.
Thus moving forward all dev code will have odd numbers, and releases will
be even 0.6 0.8 0.10 / 1.0 etc.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Release numbering suggestion
Posted by Steve Huston <sh...@riverace.com>.
> On Tue, 2009-12-22 at 11:37 -0500, Alan Conway wrote:
> > ...
> > How about we change the number to 0.7 when we branch 0.6,
> and leave it
> > 0.7 when
> > we release 0.7. There's no ambiguity: 0.7 refers to the
> code that will someday
> > be release 0.7 up to the day it actually becomes 0.7.
>
> I could certainly accept that. What I think is wrong is
> leaving the trunk with the old release number until starting
> the next release process.
I agree with that, because it is then hard to tell if you're looking at
the release or something later in the dev stream.
> > > The advantage of this scheme is that it is immediately obvious
> > > whether a given release is development or a released release (odd
> > > numbers are dev, even are release). It also means that
> the numbering
> > > is never shared between trunk and a branch.
> >
> > What's the purpose of a separate version number for in between
> > releases?
>
> Well partly it's precisely because it allow you to tell at a
> glance whether a bug report is against a released version of
> qpid or against a devel version of qpid.
>
> I think the major advantage of distinguishing between
> release/dev versions is in bug reporting and scheduling bug fixes.
But what's a dev "version"? The only time you can really have a
meaningful "version" is when it's tagged and set aside. Dev stuff is a
moving target. Any given number assigned to "dev" today is not the same
as tomorrow's.
What does it mean to schedule a fix for "dev"?
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Andrew Stitcher <as...@redhat.com>.
On Tue, 2009-12-22 at 11:37 -0500, Alan Conway wrote:
> ...
> How about we change the number to 0.7 when we branch 0.6, and leave it 0.7 when
> we release 0.7. There's no ambiguity: 0.7 refers to the code that will someday
> be release 0.7 up to the day it actually becomes 0.7.
I could certainly accept that. What I think is wrong is leaving the
trunk with the old release number until starting the next release
process.
>
> >
> > The advantage of this scheme is that it is immediately obvious whether a
> > given release is development or a released release (odd numbers are dev,
> > even are release). It also means that the numbering is never shared
> > between trunk and a branch.
>
> What's the purpose of a separate version number for in between releases?
Well partly it's precisely because it allow you to tell at a glance
whether a bug report is against a released version of qpid or against a
devel version of qpid.
I think the major advantage of distinguishing between release/dev
versions is in bug reporting and scheduling bug fixes.
I have to say that I think these are enough to make me want to do it,
but not enough that I'm totally attached to the even-odd thing.
Another point is that a number of other projects do distinguish between
dev and release versions using precisely this model - it's not a proof
that it's any good for us, but an indication that it's useful for them.
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Alan Conway <ac...@redhat.com>.
On 12/22/2009 10:43 AM, Andrew Stitcher wrote:
> We currently have a problem distinguishing between the qpid release
> numbering for actual releases and release branches and code development
> on trunk.
>
> For example before starting the 0.6 release the label 0.5 was ambiguous
> - it referred both to the development code on the and the code in the
> 0.5 release. By that I mean that the code on trunk thought it was 0.5
> too and reported that.
>
> I propose that we change the trunk numbering to 0.7 at the point we
> branch 0.6 for release.
>
> Then I propose that we change the numbering to 0.8 when we start the
> next release process.
>
> Then we would change trunk numbering to 0.9 when branching the next
> release etc.
How about we change the number to 0.7 when we branch 0.6, and leave it 0.7 when
we release 0.7. There's no ambiguity: 0.7 refers to the code that will someday
be release 0.7 up to the day it actually becomes 0.7.
>
> The advantage of this scheme is that it is immediately obvious whether a
> given release is development or a released release (odd numbers are dev,
> even are release). It also means that the numbering is never shared
> between trunk and a branch.
What's the purpose of a separate version number for in between releases?
> Minor disadvantage: Our releases skip from 0.6 to 0.8 to 0.10 etc.
>
> Comments?
>
> [unless I hear heated opposition by the actual point of release, I will
> do this]
>
Not heated opposition, I'm just not understanding the benefits.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Release numbering suggestion
Posted by Robbie Gemmell <ro...@gmail.com>.
I didn't mean X as a character, just any number...eg 0.6.1, 0.6.9. Something to distinguish from the release without burning up minor version numbers.
I think most of our releases incorporate enough change to deserve a minor version bump, and I like them being consecutive....something about 0.6, 0.8 just doesn't sit right with me, but burning micro's is fine...yes its oddball of me ;)
Robbie
> -----Original Message-----
> From: Andrew Stitcher [mailto:astitcher@redhat.com]
> Sent: 22 December 2009 18:39
> To: dev@qpid.apache.org
> Subject: RE: Release numbering suggestion
>
> On Tue, 2009-12-22 at 18:24 +0000, Robbie Gemmell wrote:
> > I would be for this if we move to major.minor.micro versions. That
> would let us e.g. tag trunk as 0.6.X following the 0.6 branch then go
> with 0.7.0 for our next release.
> >
>
> I think in practice 0.6.x is already what we do in terms of scm tags.
> However re actual embedded release versions we have to use actual
> numeric values, at least for autotools we do - so I assume this is a
> requirement.
>
> But perhaps I didn't exactly understand what you are suggesting.
>
> Andrew
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Release numbering suggestion
Posted by Andrew Stitcher <as...@redhat.com>.
On Tue, 2009-12-22 at 18:24 +0000, Robbie Gemmell wrote:
> I would be for this if we move to major.minor.micro versions. That would let us e.g. tag trunk as 0.6.X following the 0.6 branch then go with 0.7.0 for our next release.
>
I think in practice 0.6.x is already what we do in terms of scm tags.
However re actual embedded release versions we have to use actual
numeric values, at least for autotools we do - so I assume this is a
requirement.
But perhaps I didn't exactly understand what you are suggesting.
Andrew
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Release numbering suggestion
Posted by Robbie Gemmell <ro...@gmail.com>.
I would be for this if we move to major.minor.micro versions. That would let us e.g. tag trunk as 0.6.X following the 0.6 branch then go with 0.7.0 for our next release.
Robbie
> -----Original Message-----
> From: Andrew Stitcher [mailto:astitcher@redhat.com]
> Sent: 22 December 2009 15:44
> To: Qpid Dev List
> Subject: Release numbering suggestion
>
> We currently have a problem distinguishing between the qpid release
> numbering for actual releases and release branches and code development
> on trunk.
>
> For example before starting the 0.6 release the label 0.5 was ambiguous
> - it referred both to the development code on the and the code in the
> 0.5 release. By that I mean that the code on trunk thought it was 0.5
> too and reported that.
>
> I propose that we change the trunk numbering to 0.7 at the point we
> branch 0.6 for release.
>
> Then I propose that we change the numbering to 0.8 when we start the
> next release process.
>
> Then we would change trunk numbering to 0.9 when branching the next
> release etc.
>
> The advantage of this scheme is that it is immediately obvious whether
> a
> given release is development or a released release (odd numbers are
> dev,
> even are release). It also means that the numbering is never shared
> between trunk and a branch.
>
> Minor disadvantage: Our releases skip from 0.6 to 0.8 to 0.10 etc.
>
> Comments?
>
> [unless I hear heated opposition by the actual point of release, I will
> do this]
>
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Release numbering suggestion
Posted by Rafael Schloming <ra...@redhat.com>.
Andrew Stitcher wrote:
> We currently have a problem distinguishing between the qpid release
> numbering for actual releases and release branches and code development
> on trunk.
>
> For example before starting the 0.6 release the label 0.5 was ambiguous
> - it referred both to the development code on the and the code in the
> 0.5 release. By that I mean that the code on trunk thought it was 0.5
> too and reported that.
>
> I propose that we change the trunk numbering to 0.7 at the point we
> branch 0.6 for release.
>
> Then I propose that we change the numbering to 0.8 when we start the
> next release process.
>
> Then we would change trunk numbering to 0.9 when branching the next
> release etc.
>
> The advantage of this scheme is that it is immediately obvious whether a
> given release is development or a released release (odd numbers are dev,
> even are release). It also means that the numbering is never shared
> between trunk and a branch.
>
> Minor disadvantage: Our releases skip from 0.6 to 0.8 to 0.10 etc.
>
> Comments?
>
> [unless I hear heated opposition by the actual point of release, I will
> do this]
This makes sense to me. It occurs to me that "dev" versions of all our
software should probably also include the svn revision number when
reporting their version info, but even just having the even/odd
distinction would be useful.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org