qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carl Trieloff <cctriel...@redhat.com>
Subject Re: Changing the release numbering scheme (was Re: [VOTE] Version Numbers)
Date Tue, 10 Feb 2009 13:24:29 GMT
Robert Godfrey wrote:
> 2009/2/10 Aidan Skinner <aidan@apache.org>:
>> (moving this to another thread so as to make tallying the vote easier)
>> On Mon, Feb 9, 2009 at 10:56 PM, Robert Greig <robert.j.greig@gmail.com> wrote:
>>> 2009/2/9 Robert Godfrey <rob.j.godfrey@gmail.com>:
>>>> I'd rather stay on M5 and work towards a release which can be > 1.0
>>> I think it would be good to have a discussion - hopefully leading to
>>> consensus (!) - on what people think we need to have achieved to merit
>>> a 1.x release. To my mind, if people agree those items and they are
>>> different from what is in scope in our next release, that implies we
>>> don't have the correct focus for our next release(s).
>> I think that's a separate issue. We do need to talk about our release
>> process a bit more, but that's probably best done in another thread.
>> Possibly this one: http://markmail.org/message/5bxobdc23rgbmqu7
> I think we need to have a rationale for changing the release numbering
> scheme at *this* release.
> Given the lack of interoperability between components if I were only
> given the choice of 0.5 and 1.5 then I would have to pick 0.5 right
> now.  I really don't want to do that as I think 0.5 significantly
> understates the maturity of the product.
> However given we are currently scheduling the work to bring the Java
> Broker up to 0-10 support I would rather hold off changing the
> numbering scheme until that work has been done.  At that point I would
> think we could move to a version numbering scheme with a major version

If we could agree to get 0-10 into the Java Broker in a timely fashion 
and then change then
go to 1.0, I am fine with that. However, the 'M' is a pain and if we 
don't reach that point for
the next release I would prefer to go to 0.5 for the next release.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message