You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Aidan Skinner <ai...@apache.org> on 2009/02/10 00:12:19 UTC
Changing the release numbering scheme (was Re: [VOTE] Version
Numbers)
(moving this to another thread so as to make tallying the vote easier)
On Mon, Feb 9, 2009 at 10:56 PM, Robert Greig <ro...@gmail.com> wrote:
> 2009/2/9 Robert Godfrey <ro...@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
> My own view is that Mx is a weak numbering scheme - something I have
> always felt and I have no idea why incubator projects have to be
> numbered (or should I say encumbered) in such a way. I am not sure
They're not. I'm not sure where that idea originated, but it's never
been a requirement for podlings to release Mx numbered artifacts. I
think the "all podling release have to be M.x releases" fallacy is an
instance of the monkey/hose/banana problem[1].
> I also seem to recall that some people brought up the point a while
> ago that certain unix package systems (e.g. rpm) only work with an
> x.y.z release numbering scheme, so we already have some use of an
> alternative scheme (or am I mistaken)?
RPM can deal with a lot of things in the version number, it's autoconf
that's a problem. The C++ bits already ship as 0.x artifacts as a
result. The main uncontroversial reason I can put forward for dropping
the M at this point is that then we have a consistent number across
all the bits, which is nice.
- Aidan
[1] http://www.b-list.org/weblog/2008/dec/05/python-3000/
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Changing the release numbering scheme (was Re: [VOTE] Version
Numbers)
Posted by Aidan Skinner <ai...@apache.org>.
On Tue, Feb 10, 2009 at 1:49 PM, Carl Trieloff <cc...@redhat.com> wrote:
> I don't care when we decide to call it 1.0, but a would like to get rid of
> the 'M'
Totally. Death to the M! ;)
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Changing the release numbering scheme (was Re: [VOTE] Version
Numbers)
Posted by Carl Trieloff <cc...@redhat.com>.
Aidan Skinner wrote:
> On Tue, Feb 10, 2009 at 1:24 PM, Carl Trieloff <cc...@redhat.com> wrote:
>
>
>> 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.
>>
>
> I don't think that adding 0-10 support to the Java broker is the only
> step necessary before we declare ourselves 1.0. I'm not sure that
> there's a consensus around what would be Qpid 1.0 just now.
>
I don't care when we decide to call it 1.0, but a would like to get rid
of the 'M'
Carl.
Re: Changing the release numbering scheme (was Re: [VOTE] Version
Numbers)
Posted by Aidan Skinner <ai...@gmail.com>.
On Tue, Feb 10, 2009 at 9:34 PM, Rafael Schloming <ra...@redhat.com> wrote:
> Aidan Skinner wrote:
>> I don't think that adding 0-10 support to the Java broker is the only
>> step necessary before we declare ourselves 1.0. I'm not sure that
>> there's a consensus around what would be Qpid 1.0 just now.
>
> What else do you feel is necessary? For me it's all about interop across the
> different languages, and the biggest part of that is 0-10 support in the
> Java broker. I'd also like to see some progress on protocol neutral APIs in
> other languages, but I actually think thats an area where we can whip things
> into shape with relatively little work.
Interop and stable APIs are the two things for me. I'm not sure that
protocol-neutral APIs are necessary so long as they'd at least be
backwards compatible from then on out until a major rev eg. when
everything spoke AMQP 1-0 and only 1-0.
I don't think we're that far away from a N.0 either FWIW, just clarify
what we mean and what we need to do to get there.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Changing the release numbering scheme (was Re: [VOTE] Version
Numbers)
Posted by Rajith Attapattu <ra...@gmail.com>.
For me the minimum for us to call X.0 is that we have stable API's that can
garuntee backwards compatibility.
Perhaps we should aim for protocol version neutral APIs in our next release.
If it takes an extra month or two, so be it.
This might not be difficult as we have spec people on this project who have
a lot of visibility on how the AMQP 1.0 would look like.
A nice to have feature is that the java broker is also 0-10, allthough this
is not a must.
Regards,
Rajith
>> I think that protocol-neutral API is going to end up a larger effort
>> than protocol implementation/interop. It ripples very far. It's also
>> what most newcomers will be affected most by as they start to look at
>> how to use Qpid for projects.
>>
>
> I certainly agree consistency and ease-of-use need to be a focus, but for
> me the minimum bar for X.0 is that we can update the protocol version
> without breaking deployed apps. The current APIs are mostly there, but there
> are a few spots where they are a bit too close to the wire and should have
> something slightly higher level in place. I think once we achieve this level
> then consistency and ease-of-use can be done with backwards compatible
> changes.
>
> --Rafael
>
>
>
> ---------------------------------------------------------------------
> 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/
Re: Changing the release numbering scheme (was Re: [VOTE] Version
Numbers)
Posted by Rafael Schloming <ra...@redhat.com>.
Steve Huston wrote:
>> Aidan Skinner wrote:
>>> On Tue, Feb 10, 2009 at 1:24 PM, Carl Trieloff
>> <cc...@redhat.com> wrote:
>>>> 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.
>>> I don't think that adding 0-10 support to the Java broker
>> is the only
>>> step necessary before we declare ourselves 1.0. I'm not sure that
>>> there's a consensus around what would be Qpid 1.0 just now.
>> What else do you feel is necessary?
>
> I think the API consistency/ease-of-use is more of an issue than the
> protocol compatibility.
>
>> For me it's all about interop across
>> the different languages, and the biggest part of that is 0-10
>> support in the Java broker.
>
> Ok.
>
>> I'd also like to see some progress on protocol neutral
>> APIs in other languages, but I actually think thats an area
>> where we can whip things into shape with relatively little work.
>
> I think that protocol-neutral API is going to end up a larger effort
> than protocol implementation/interop. It ripples very far. It's also
> what most newcomers will be affected most by as they start to look at
> how to use Qpid for projects.
I certainly agree consistency and ease-of-use need to be a focus, but
for me the minimum bar for X.0 is that we can update the protocol
version without breaking deployed apps. The current APIs are mostly
there, but there are a few spots where they are a bit too close to the
wire and should have something slightly higher level in place. I think
once we achieve this level then consistency and ease-of-use can be done
with backwards compatible changes.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: Changing the release numbering scheme (was Re: [VOTE] Version Numbers)
Posted by Steve Huston <sh...@riverace.com>.
> Aidan Skinner wrote:
> > On Tue, Feb 10, 2009 at 1:24 PM, Carl Trieloff
> <cc...@redhat.com> wrote:
> >
> >> 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.
> >
> > I don't think that adding 0-10 support to the Java broker
> is the only
> > step necessary before we declare ourselves 1.0. I'm not sure that
> > there's a consensus around what would be Qpid 1.0 just now.
>
> What else do you feel is necessary?
I think the API consistency/ease-of-use is more of an issue than the
protocol compatibility.
> For me it's all about interop across
> the different languages, and the biggest part of that is 0-10
> support in the Java broker.
Ok.
> I'd also like to see some progress on protocol neutral
> APIs in other languages, but I actually think thats an area
> where we can whip things into shape with relatively little work.
I think that protocol-neutral API is going to end up a larger effort
than protocol implementation/interop. It ripples very far. It's also
what most newcomers will be affected most by as they start to look at
how to use Qpid for projects.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Changing the release numbering scheme (was Re: [VOTE] Version
Numbers)
Posted by Rafael Schloming <ra...@redhat.com>.
Aidan Skinner wrote:
> On Tue, Feb 10, 2009 at 1:24 PM, Carl Trieloff <cc...@redhat.com> wrote:
>
>> 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.
>
> I don't think that adding 0-10 support to the Java broker is the only
> step necessary before we declare ourselves 1.0. I'm not sure that
> there's a consensus around what would be Qpid 1.0 just now.
What else do you feel is necessary? For me it's all about interop across
the different languages, and the biggest part of that is 0-10 support in
the Java broker. I'd also like to see some progress on protocol neutral
APIs in other languages, but I actually think thats an area where we can
whip things into shape with relatively little work.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Changing the release numbering scheme (was Re: [VOTE] Version
Numbers)
Posted by Aidan Skinner <ai...@apache.org>.
On Tue, Feb 10, 2009 at 1:24 PM, Carl Trieloff <cc...@redhat.com> wrote:
> 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.
I don't think that adding 0-10 support to the Java broker is the only
step necessary before we declare ourselves 1.0. I'm not sure that
there's a consensus around what would be Qpid 1.0 just now.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Changing the release numbering scheme (was Re: [VOTE] Version
Numbers)
Posted by Carl Trieloff <cc...@redhat.com>.
Robert Godfrey wrote:
> 2009/2/10 Aidan Skinner <ai...@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 <ro...@gmail.com> wrote:
>>
>>
>>> 2009/2/9 Robert Godfrey <ro...@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.
Carl
Re: Changing the release numbering scheme (was Re: [VOTE] Version
Numbers)
Posted by Robert Godfrey <ro...@gmail.com>.
2009/2/10 Aidan Skinner <ai...@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 <ro...@gmail.com> wrote:
>
>> 2009/2/9 Robert Godfrey <ro...@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
> 0. This would make me happy.
-- Rob
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Changing the release numbering scheme (was Re: [VOTE] Version
Numbers)
Posted by Marnie McCormack <ma...@googlemail.com>.
I can understand the various views of what we need to achieve to call Qpid a
more complete product. I agree with many of the goals put forward and I'm
glad we're discussing them.
However, we have been on the go with releases that users have deployed into
production since 2006. For me, the notion that we're less than 1.0 is
somewhat nonsensical given production applications of Qpid and the
robustness & reliability of the Java components (at least, other elements
outside my ken).
The clients/brokers have historically interop-ed and we have made some poor
decisions subsequently. I'm not sure that takes us directly backwards.
However, this is not an area I'm that passionate about. I guess my point is
that I think we need to be careful about putting too much significance on
the "version number as project description" view.
We absolutely do need to have a coherent set of project goals, including
inter-op, API changes, feature compability etc. Essentially the numbering of
our releases will not be that significant to our users (I am never, ever
asked about the number - a comprehensive test suite with published results
benchmarked would be a far more compelling argument for use.)
I'd find it hard to explain to users with production deployments that we're
somehow a less than 1.0 product. For me, we're hanging other (important)
project discussions off the wrong hook.
My tuppence ...
Marnie
On Tue, Feb 10, 2009 at 9:56 PM, Robert Greig <ro...@gmail.com>wrote:
> 2009/2/9 Aidan Skinner <ai...@apache.org>:
>
> >> 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
>
> Well, people seem to have a view that we need to have certain features
> (APIs, protocol compatibility) to be able to have an X.0 release so I
> think it is directly related.
>
> I don't think it's related to our release process though?
>
> >> My own view is that Mx is a weak numbering scheme - something I have
> >> always felt and I have no idea why incubator projects have to be
> >> numbered (or should I say encumbered) in such a way. I am not sure
> >
> > They're not. I'm not sure where that idea originated, but it's never
> > been a requirement for podlings to release Mx numbered artifacts. I
> > think the "all podling release have to be M.x releases" fallacy is an
> > instance of the monkey/hose/banana problem[1].
>
> Interesting, I wonder how we ended up with such a poor numbering
> scheme in the first place. Anyway, that is a historical detail now I
> suppose.
>
> RG
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: Changing the release numbering scheme (was Re: [VOTE] Version
Numbers)
Posted by Aidan Skinner <ai...@gmail.com>.
On Tue, Feb 10, 2009 at 9:56 PM, Robert Greig <ro...@gmail.com> wrote:
> 2009/2/9 Aidan Skinner <ai...@apache.org>:
>
>>> 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
>
> Well, people seem to have a view that we need to have certain features
> (APIs, protocol compatibility) to be able to have an X.0 release so I
> think it is directly related.
>
> I don't think it's related to our release process though?
Sorry, the 'seperate issue' bit was whether it should be in scope for
our next release or not, not that we shouldn't figure out what 1.0
would look like. Totally wasn't clear from what I'd written and
quoted.
>>> My own view is that Mx is a weak numbering scheme - something I have
>>> always felt and I have no idea why incubator projects have to be
>>> numbered (or should I say encumbered) in such a way. I am not sure
>>
>> They're not. I'm not sure where that idea originated, but it's never
>> been a requirement for podlings to release Mx numbered artifacts. I
>> think the "all podling release have to be M.x releases" fallacy is an
>> instance of the monkey/hose/banana problem[1].
>
> Interesting, I wonder how we ended up with such a poor numbering
> scheme in the first place. Anyway, that is a historical detail now I
> suppose.
Yeah, spilt version numbers and all that. :)
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: Changing the release numbering scheme (was Re: [VOTE] Version
Numbers)
Posted by Robert Greig <ro...@gmail.com>.
2009/2/9 Aidan Skinner <ai...@apache.org>:
>> 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
Well, people seem to have a view that we need to have certain features
(APIs, protocol compatibility) to be able to have an X.0 release so I
think it is directly related.
I don't think it's related to our release process though?
>> My own view is that Mx is a weak numbering scheme - something I have
>> always felt and I have no idea why incubator projects have to be
>> numbered (or should I say encumbered) in such a way. I am not sure
>
> They're not. I'm not sure where that idea originated, but it's never
> been a requirement for podlings to release Mx numbered artifacts. I
> think the "all podling release have to be M.x releases" fallacy is an
> instance of the monkey/hose/banana problem[1].
Interesting, I wonder how we ended up with such a poor numbering
scheme in the first place. Anyway, that is a historical detail now I
suppose.
RG
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org