You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Carl Trieloff <cc...@redhat.com> on 2009/02/02 23:44:50 UTC
version number proposal
Short and sweet... I propose we move from Mx naming and with M5 move to
1.5 then 1.6 and so forth.
any takers?
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: version number proposal
Posted by Carl Trieloff <cc...@redhat.com>.
Carl Trieloff wrote:
> Steve Huston wrote:
>> Hi Carl,
>>
>>
>>> Short and sweet... I propose we move from Mx naming and with M5 move
>>> to 1.5 then 1.6 and so forth.
>>>
>>> any takers?
>>>
>>
>> Another possibility... Go to 0.5, 0.6, etc. until a version is done
>> that supports AMQP 1.0 and that is Qpid 1.0.
>>
>
> Personally I think it is better to have no connection between our
> versions and spec versions. Else
> what does it mean if we go to 2.0?
i.e. if we went 0.5 0.6 etc, going 1.0 should NOT be tied to spec
version in my view
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: version number proposal
Posted by Steve Huston <sh...@riverace.com>.
> >> Short and sweet... I propose we move from Mx naming and with
> >> M5 move to 1.5 then 1.6 and so forth.
> >>
> >> any takers?
> >>
> >
> > Another possibility... Go to 0.5, 0.6, etc. until a version is
done
> > that supports AMQP 1.0 and that is Qpid 1.0.
> >
>
> Personally I think it is better to have no connection between our
> versions and spec versions. Else what does it mean if we go to 2.0?
Right, good point.
I'm +1 on the 1.5 plan to replace M5.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: version number proposal
Posted by Carl Trieloff <cc...@redhat.com>.
Steve Huston wrote:
> Hi Carl,
>
>
>> Short and sweet... I propose we move from Mx naming and with
>> M5 move to 1.5 then 1.6 and so forth.
>>
>> any takers?
>>
>
> Another possibility... Go to 0.5, 0.6, etc. until a version is done
> that supports AMQP 1.0 and that is Qpid 1.0.
>
Personally I think it is better to have no connection between our
versions and spec versions. Else
what does it mean if we go to 2.0?
Carl.
Re: version number proposal
Posted by Aidan Skinner <ai...@gmail.com>.
On Thu, Feb 5, 2009 at 1:10 PM, Carl Trieloff <cc...@redhat.com> wrote:
> Aidan Skinner wrote:
>> Having the choice would be good, I'd rather stick with M5 than 1.5,
>> but would prefer 0.5 to either.
>
> Clearly everyone is not going to agree on this eg. Rob Grieg feels one way
> you the other. It is going
> to come down to vote the choice and go with the one that wins.
>
> that ok?
Oh, yeah, totally. I was just saying I think we should have a vote
which included both options rather than on M5 vs just one of them.
Condorcet voting would be handy here, but I don't think the ASF is set
up for 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: version number proposal
Posted by Carl Trieloff <cc...@redhat.com>.
Aidan Skinner wrote:
> On Thu, Feb 5, 2009 at 12:56 PM, Carl Trieloff <cc...@redhat.com> wrote:
>
>
>> Shall I make my proposal again... v1.5 for the next release? or shall I
>> create a vote with 1.5 & 0.5
>> and people can only vote for one of them
>>
>
> Having the choice would be good, I'd rather stick with M5 than 1.5,
> but would prefer 0.5 to either.
Clearly everyone is not going to agree on this eg. Rob Grieg feels one
way you the other. It is going
to come down to vote the choice and go with the one that wins.
that ok?
Carl.
Re: version number proposal
Posted by Aidan Skinner <ai...@gmail.com>.
On Thu, Feb 5, 2009 at 12:56 PM, Carl Trieloff <cc...@redhat.com> wrote:
> Shall I make my proposal again... v1.5 for the next release? or shall I
> create a vote with 1.5 & 0.5
> and people can only vote for one of them
Having the choice would be good, I'd rather stick with M5 than 1.5,
but would prefer 0.5 to either.
- Aian
--
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: version number proposal
Posted by Carl Trieloff <cc...@redhat.com>.
Robert Greig wrote:
> 2009/2/3 Rafael Schloming <ra...@redhat.com>:
>
>
>>> I could buy into s/M/0./ for everything (but not s/M/1./). I know some
>>> people are opposed to releasing 0.x versions for marketing reasons,
>>> but that essentially removes any useful information from the rev.
>>>
>> I agree, and personally I don't think marketing should enter into the
>> version number discussion. I think once you let marketing in, you've removed
>> all hope for sane and useful version numbers. ;)
>>
>
> I don't think the 1.x argument is about marketing, really. It's about
> conveying information that reflects accepted understanding of the
> meaning contained in the number. A 0.x release implies to many people
> a low level of maturity and stability. Certainly looking at the Java
> broker and client, only because I a most familiar with those, I know
> that they have many production installations today delivering
> business-critical messages. By labelling that 0.x I think it is
> painting a false impression of the maturity of the software - which is
> now several years old. Are we really saying that after three years
> qpid isn't even 1.x?
>
> I do also agree that 1.x implies a certain level of API compatibility
> - but I can smugly say that I have consistently argued on this forum
> that building an API that is closely tied to AMQP is insane. Maybe
> this implies that for the next release the non-Java languages need to
> focus on the API design. Or we should be comfortable moving to 2.x
> relatively quickly as the API evolves.
based on the threads
Shall I make my proposal again... v1.5 for the next release? or shall I
create a vote with 1.5 & 0.5
and people can only vote for one of them
Carl.
Re: version number proposal
Posted by Carl Trieloff <cc...@redhat.com>.
Martin Ritchie wrote:
> I think we should have a third option:
>
> Stay with Mx for now, M5
>
I don't think there is any point in that, let's close the issue
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: version number proposal
Posted by Martin Ritchie <ri...@apache.org>.
I think we should have a third option:
Stay with Mx for now, M5
Martin
On 09/02/2009, Carl Trieloff <cc...@redhat.com> wrote:
> Aidan Skinner wrote:
>> On Thu, Feb 5, 2009 at 3:06 PM, Carl Trieloff <cc...@redhat.com>
>> wrote:
>>
>>
>>> let's bring this thread back on topic....
>>> straw poll, select one.
>>>
>>> [ ] 0.5
>>> [ ] 1.5
>>>
>>
>> I'm in favour of 0.5. It's probably worth having an official [VOTE] on
>> this, I suspect some people may have killfiled this thread. ;)
>>
>> - Aidan
>>
>
> Aidan,
>
> Can you start the vote with the two options. let's get this topic closed.
>
> Carl.
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: version number proposal
Posted by Carl Trieloff <cc...@redhat.com>.
Aidan Skinner wrote:
> On Thu, Feb 5, 2009 at 3:06 PM, Carl Trieloff <cc...@redhat.com> wrote:
>
>
>> let's bring this thread back on topic....
>> straw poll, select one.
>>
>> [ ] 0.5
>> [ ] 1.5
>>
>
> I'm in favour of 0.5. It's probably worth having an official [VOTE] on
> this, I suspect some people may have killfiled this thread. ;)
>
> - Aidan
>
Aidan,
Can you start the vote with the two options. let's get this topic closed.
Carl.
Re: version number proposal
Posted by Aidan Skinner <ai...@apache.org>.
On Thu, Feb 5, 2009 at 3:06 PM, Carl Trieloff <cc...@redhat.com> wrote:
>
> let's bring this thread back on topic....
> straw poll, select one.
>
> [ ] 0.5
> [ ] 1.5
I'm in favour of 0.5. It's probably worth having an official [VOTE] on
this, I suspect some people may have killfiled this thread. ;)
- 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: version number proposal
Posted by Steve Huston <sh...@riverace.com>.
[x] 0.5
-Steve
> -----Original Message-----
> From: Carl Trieloff [mailto:cctrieloff@redhat.com]
> Sent: Thursday, February 05, 2009 10:06 AM
> To: dev@qpid.apache.org
> Subject: Re: version number proposal
>
>
>
> let's bring this thread back on topic....
> straw poll, select one.
>
> [ ] 0.5
> [ ] 1.5
>
> Both work, take your pick. many OS projects use pre 1 numbering and
> others use bigger numbers.
>
>
>
>
---------------------------------------------------------------------
> 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: version number proposal
Posted by Robert Godfrey <ro...@gmail.com>.
>From what I can see the source of peoples differing feelings isn't
over arbitrary versioning conventions, but rather over the direction
and state of the project as a whole. I think everyone actually has a
relatively similar notion of what 1.x vs 0.x means, but they're simply
applying it to with different priority to different portions of the
project.
Further I don't see a pressing reason to change the version numbering
scheme at this release. As far as I can tell we are not aiming for
this release to bring either major functional changes or levels of
maturity that would in itself warrant a change of versioning scheme.
My preference would be to leave the existing scheme in place as a
reminder to us all that the priority must be to bring more cohesion to
the project so that a common versioning scheme makes sense. We should
be aiming to release a coherent product which interoperates across all
platforms and gives our users a promise of some period of API
stability. When we have achieved this then we can (with a fanfare)
release as version X.0 where X is yet to be decided.
--Rob
2009/2/5 Rajith Attapattu <ra...@gmail.com>:
> [x] 0.5
>
> Regards,
>
> Rajith
>
> On Thu, Feb 5, 2009 at 10:06 AM, Carl Trieloff <cc...@redhat.com>wrote:
>
>>
>> let's bring this thread back on topic....
>> straw poll, select one.
>>
>> [ ] 0.5
>> [ ] 1.5
>>
>> Both work, take your pick. many OS projects use pre 1 numbering and others
>> use bigger numbers.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: version number proposal
Posted by Rajith Attapattu <ra...@gmail.com>.
[x] 0.5
Regards,
Rajith
On Thu, Feb 5, 2009 at 10:06 AM, Carl Trieloff <cc...@redhat.com>wrote:
>
> let's bring this thread back on topic....
> straw poll, select one.
>
> [ ] 0.5
> [ ] 1.5
>
> Both work, take your pick. many OS projects use pre 1 numbering and others
> use bigger numbers.
>
>
>
>
> ---------------------------------------------------------------------
> 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: version number proposal
Posted by Marnie McCormack <ma...@googlemail.com>.
[x] 1.5
Marnie
On Thu, Feb 5, 2009 at 3:06 PM, Carl Trieloff <cc...@redhat.com> wrote:
>
> let's bring this thread back on topic....
> straw poll, select one.
>
> [ ] 0.5
> [ ] 1.5
>
> Both work, take your pick. many OS projects use pre 1 numbering and others
> use bigger numbers.
>
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: version number proposal
Posted by Carl Trieloff <cc...@redhat.com>.
let's bring this thread back on topic....
straw poll, select one.
[ ] 0.5
[ ] 1.5
Both work, take your pick. many OS projects use pre 1 numbering and
others use bigger numbers.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: version number proposal
Posted by Rafael Schloming <ra...@redhat.com>.
Martin Ritchie wrote:
> 2009/2/5 Rafael Schloming <ra...@redhat.com>:
>> Robert Greig wrote:
>>> 2009/2/3 Rafael Schloming <ra...@redhat.com>:
>>>
>>>>> I could buy into s/M/0./ for everything (but not s/M/1./). I know some
>>>>> people are opposed to releasing 0.x versions for marketing reasons,
>>>>> but that essentially removes any useful information from the rev.
>>>> I agree, and personally I don't think marketing should enter into the
>>>> version number discussion. I think once you let marketing in, you've
>>>> removed
>>>> all hope for sane and useful version numbers. ;)
>>> I don't think the 1.x argument is about marketing, really. It's about
>>> conveying information that reflects accepted understanding of the
>>> meaning contained in the number. A 0.x release implies to many people
>>> a low level of maturity and stability. Certainly looking at the Java
>>> broker and client, only because I a most familiar with those, I know
>>> that they have many production installations today delivering
>>> business-critical messages. By labelling that 0.x I think it is
>>> painting a false impression of the maturity of the software - which is
>>> now several years old. Are we really saying that after three years
>>> qpid isn't even 1.x?
>>>
>>> I do also agree that 1.x implies a certain level of API compatibility
>>> - but I can smugly say that I have consistently argued on this forum
>>> that building an API that is closely tied to AMQP is insane. Maybe
>>> this implies that for the next release the non-Java languages need to
>>> focus on the API design. Or we should be comfortable moving to 2.x
>>> relatively quickly as the API evolves.
>> If we had *some* API other than JMS then labeling it 1.x might be reasonable
>> even if we expect to have a 2.x coming up, but for me at least, what we have
>> doesn't constitute enough of an abstraction to be labeled a 1.x since that
>> implies we have confidence in our ability to go from 1.x to 1.x+1 without
>> breaking the API, and I don't think we're there yet.
>>
>> I think if you're concerned with the 0.x moniker implying instability then
>> maybe we should stick with Mx and make it a high priority to build out the
>> non Java client APIs.
>
> I'm +1 on that.
>
> Implementing an API that exists on each platform for messaging seems
> like the way to go.
> Obviously only if there is such an API. I know at least C# has a
> standard System.Messaging but does Ruby, Python and C++ have simlar
> platform Messaging APIs?
>
> I don't think we should be making one up, especially as some of us our
> JMS API tainted.
>
> I'd say the best way to go is to reuse already well known and accepted
> APIs where we can. Is someone willing to look in to what APIs we could
> use?
I can't comment on C++, but as far as I know there isn't any sort of
standard messaging API for python or ruby. I think a reasonable approach
for both python and ruby would be to take the basic nouns and verbs from
JMS (Connection, Session, Producer, Consumer, Message), and hang them
together in a similar manner to JMS, but use appropriate idioms from the
respective languages.
I don't know about the implications of this approach relative to
JMS-taint, but I know python standard library has done similar things
with other Java APIs, e.g. the python threading module.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: version number proposal
Posted by Martin Ritchie <ri...@apache.org>.
2009/2/5 Rafael Schloming <ra...@redhat.com>:
> Robert Greig wrote:
>>
>> 2009/2/3 Rafael Schloming <ra...@redhat.com>:
>>
>>>> I could buy into s/M/0./ for everything (but not s/M/1./). I know some
>>>> people are opposed to releasing 0.x versions for marketing reasons,
>>>> but that essentially removes any useful information from the rev.
>>>
>>> I agree, and personally I don't think marketing should enter into the
>>> version number discussion. I think once you let marketing in, you've
>>> removed
>>> all hope for sane and useful version numbers. ;)
>>
>> I don't think the 1.x argument is about marketing, really. It's about
>> conveying information that reflects accepted understanding of the
>> meaning contained in the number. A 0.x release implies to many people
>> a low level of maturity and stability. Certainly looking at the Java
>> broker and client, only because I a most familiar with those, I know
>> that they have many production installations today delivering
>> business-critical messages. By labelling that 0.x I think it is
>> painting a false impression of the maturity of the software - which is
>> now several years old. Are we really saying that after three years
>> qpid isn't even 1.x?
>>
>> I do also agree that 1.x implies a certain level of API compatibility
>> - but I can smugly say that I have consistently argued on this forum
>> that building an API that is closely tied to AMQP is insane. Maybe
>> this implies that for the next release the non-Java languages need to
>> focus on the API design. Or we should be comfortable moving to 2.x
>> relatively quickly as the API evolves.
>
> If we had *some* API other than JMS then labeling it 1.x might be reasonable
> even if we expect to have a 2.x coming up, but for me at least, what we have
> doesn't constitute enough of an abstraction to be labeled a 1.x since that
> implies we have confidence in our ability to go from 1.x to 1.x+1 without
> breaking the API, and I don't think we're there yet.
>
> I think if you're concerned with the 0.x moniker implying instability then
> maybe we should stick with Mx and make it a high priority to build out the
> non Java client APIs.
I'm +1 on that.
Implementing an API that exists on each platform for messaging seems
like the way to go.
Obviously only if there is such an API. I know at least C# has a
standard System.Messaging but does Ruby, Python and C++ have simlar
platform Messaging APIs?
I don't think we should be making one up, especially as some of us our
JMS API tainted.
I'd say the best way to go is to reuse already well known and accepted
APIs where we can. Is someone willing to look in to what APIs we could
use?
Martin
> --Rafael
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Martin Ritchie
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: version number proposal
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Greig wrote:
> 2009/2/3 Rafael Schloming <ra...@redhat.com>:
>
>>> I could buy into s/M/0./ for everything (but not s/M/1./). I know some
>>> people are opposed to releasing 0.x versions for marketing reasons,
>>> but that essentially removes any useful information from the rev.
>> I agree, and personally I don't think marketing should enter into the
>> version number discussion. I think once you let marketing in, you've removed
>> all hope for sane and useful version numbers. ;)
>
> I don't think the 1.x argument is about marketing, really. It's about
> conveying information that reflects accepted understanding of the
> meaning contained in the number. A 0.x release implies to many people
> a low level of maturity and stability. Certainly looking at the Java
> broker and client, only because I a most familiar with those, I know
> that they have many production installations today delivering
> business-critical messages. By labelling that 0.x I think it is
> painting a false impression of the maturity of the software - which is
> now several years old. Are we really saying that after three years
> qpid isn't even 1.x?
>
> I do also agree that 1.x implies a certain level of API compatibility
> - but I can smugly say that I have consistently argued on this forum
> that building an API that is closely tied to AMQP is insane. Maybe
> this implies that for the next release the non-Java languages need to
> focus on the API design. Or we should be comfortable moving to 2.x
> relatively quickly as the API evolves.
If we had *some* API other than JMS then labeling it 1.x might be
reasonable even if we expect to have a 2.x coming up, but for me at
least, what we have doesn't constitute enough of an abstraction to be
labeled a 1.x since that implies we have confidence in our ability to go
from 1.x to 1.x+1 without breaking the API, and I don't think we're
there yet.
I think if you're concerned with the 0.x moniker implying instability
then maybe we should stick with Mx and make it a high priority to build
out the non Java client APIs.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: version number proposal
Posted by Robert Greig <ro...@gmail.com>.
2009/2/3 Rafael Schloming <ra...@redhat.com>:
>> I could buy into s/M/0./ for everything (but not s/M/1./). I know some
>> people are opposed to releasing 0.x versions for marketing reasons,
>> but that essentially removes any useful information from the rev.
>
> I agree, and personally I don't think marketing should enter into the
> version number discussion. I think once you let marketing in, you've removed
> all hope for sane and useful version numbers. ;)
I don't think the 1.x argument is about marketing, really. It's about
conveying information that reflects accepted understanding of the
meaning contained in the number. A 0.x release implies to many people
a low level of maturity and stability. Certainly looking at the Java
broker and client, only because I a most familiar with those, I know
that they have many production installations today delivering
business-critical messages. By labelling that 0.x I think it is
painting a false impression of the maturity of the software - which is
now several years old. Are we really saying that after three years
qpid isn't even 1.x?
I do also agree that 1.x implies a certain level of API compatibility
- but I can smugly say that I have consistently argued on this forum
that building an API that is closely tied to AMQP is insane. Maybe
this implies that for the next release the non-Java languages need to
focus on the API design. Or we should be comfortable moving to 2.x
relatively quickly as the API evolves.
RG
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: version number proposal
Posted by Aidan Skinner <ai...@apache.org>.
On Tue, Feb 3, 2009 at 1:34 PM, Carl Trieloff <cc...@redhat.com> wrote:
> Marnie McCormack wrote:
>>
>> I am not passionate about version numbers or marketing etc etc, but at
>> risk
>> of physical harm from my right hand side .. i think having different
>> versions for the different bits is very consuing for users.
>>
>> I'm all for 1.6 or even 0.6 across the board next time.
>>
>> My kevlar will be arriving soon.
>
> +1 -- well said Marnie
Seems like we're coming to a consensus on s/M/0./...
- 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: version number proposal
Posted by Carl Trieloff <cc...@redhat.com>.
Marnie McCormack wrote:
> I am not passionate about version numbers or marketing etc etc, but at risk
> of physical harm from my right hand side .. i think having different
> versions for the different bits is very consuing for users.
>
> I'm all for 1.6 or even 0.6 across the board next time.
>
> My kevlar will be arriving soon.
+1 -- well said Marnie
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: version number proposal
Posted by Marnie McCormack <ma...@googlemail.com>.
I am not passionate about version numbers or marketing etc etc, but at risk
of physical harm from my right hand side .. i think having different
versions for the different bits is very consuing for users.
I'm all for 1.6 or even 0.6 across the board next time.
My kevlar will be arriving soon.
Marnie
On Tue, Feb 3, 2009 at 12:05 PM, Rafael Schloming <ra...@redhat.com>wrote:
> Aidan Skinner wrote:
>
>> I'm of two minds on this. On the one hand I think your proposal probably
>>> most accurately reflects the reality of the current situation. On the
>>> other
>>> hand, I don't think the current situation is really a great place for us
>>> to
>>> be as a project.
>>>
>>
>> I think version numbers which reflect reality is probably a plus. I
>> don't think it would be detrimental to the one team, one project, one
>> qpid goal. There are definately issues there, but I don't think
>> independently varying version numbers would add to those.
>>
>
> Part of my point is that the extent to which they reflect reality depends
> on where you want things to be going.
>
> One view is that JMS is API stable, and other clients are not, therefore
> JMS gets a nice stable version number, and the other components don't.
> However in some ways that's a bit missleading since we're not trying to
> version the JMS API (we don't need to, it already has its own version
> number), we're versioning our *implementation* of JMS, and to a much greater
> extent the maturity of our *implementation* does depend on the other pieces
> of the project, e.g. the broker, and the level of interop with other
> clients, and one version number better reflects *that* reality.
>
> In particular, one of the core goals of qpid is to provide a consistent
>>> cross-language messaging experience, and that includes equivalently
>>> stable
>>> and similar looking/feeling APIs across all the client languages we
>>> support.
>>>
>>
>> I'm not sure that similar looking/feeling APIs are really desierable.
>> I'd rather see idiomatic APIs that feel comfortable and natural in the
>> language than shoe-horning JMS into C++.
>>
>
> I'm not sure what would require shoe-horning. The JMS API is very simple,
> and could easily be translated idiomatically into any of our current client
> languages, e.g in ruby it would be quite possible to model connection,
> session, producer, consumer, and message and yet still have
> consumer.on_message {|m| blah ... } rather than
> consumer.setMessageListener(...).
>
> That said, my statement in no way implied that we should mindlessly
> translate JMS into the other languages, simply that we need some set of APIs
> that are at a similar level of abstraction such that they can each support
> multiple protocols underneath.
>
> The fact of the matter is that the various clients and brokers are at
>> differing levels of robustness, internal stability and API stability
>> and that's not something that I really see changing anytime soon.
>>
>
> Actually at the moment I think they're all fairly close. There are really
> only two outliers: JMS and dotnet. JMS being more API stable due to being
> JMS, and dotnet being in an exceptional category at the moment since we
> haven't really settled on how we're going to provide something there in a
> sustainable manner going forward.
>
> IMHO the appropriate way to make the situation with the JMS client clear is
> to actually state on our download page that it is a JMS client, and maybe
> even put JMS in the artifact name. This will have infinitely more meaning
> than any version number choice.
>
> As for dotnet, I think that probably deserves its own discussion, since the
> issue there is really more about how we are going to maintain the thing
> going forward, and less about what it's current version number should be.
>
> So for me, I'd either stick with the Mx version numbers, or use a pre 1.0
>>> version numbering scheme until we've reached that goal of a consistent
>>> cross
>>> language messaging experience, and only from there move into post 1.0
>>> territory.
>>>
>>
>> I could buy into s/M/0./ for everything (but not s/M/1./). I know some
>> people are opposed to releasing 0.x versions for marketing reasons,
>> but that essentially removes any useful information from the rev.
>>
>
> I agree, and personally I don't think marketing should enter into the
> version number discussion. I think once you let marketing in, you've removed
> all hope for sane and useful version numbers. ;)
>
> --Rafael
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: version number proposal
Posted by Aidan Skinner <ai...@gmail.com>.
On Tue, Feb 3, 2009 at 12:05 PM, Rafael Schloming <ra...@redhat.com> wrote:
> Aidan Skinner wrote:
> One view is that JMS is API stable, and other clients are not, therefore JMS
> gets a nice stable version number, and the other components don't. However
> in some ways that's a bit missleading since we're not trying to version the
> JMS API (we don't need to, it already has its own version number), we're
> versioning our *implementation* of JMS, and to a much greater extent the
> maturity of our *implementation* does depend on the other pieces of the
> project, e.g. the broker, and the level of interop with other clients, and
> one version number better reflects *that* reality.
That's a fair point. I hate multiple realities. Damn you Hugh Everett!
>> I'm not sure that similar looking/feeling APIs are really desierable.
>> I'd rather see idiomatic APIs that feel comfortable and natural in the
>> language than shoe-horning JMS into C++.
> That said, my statement in no way implied that we should mindlessly
> translate JMS into the other languages, simply that we need some set of APIs
> that are at a similar level of abstraction such that they can each support
> multiple protocols underneath.
I misinterpreted you in that case, those are both things I can get behind. :)
> As for dotnet, I think that probably deserves its own discussion, since the
> issue there is really more about how we are going to maintain the thing
> going forward, and less about what it's current version number should be.
Yeah, totally different thread that one.
>> I could buy into s/M/0./ for everything (but not s/M/1./). I know some
>> people are opposed to releasing 0.x versions for marketing reasons,
>> but that essentially removes any useful information from the rev.
>
> I agree, and personally I don't think marketing should enter into the
> version number discussion. I think once you let marketing in, you've removed
> all hope for sane and useful version numbers. ;)
Indeed, incrementing releases are the way that goes and often not even
monotonically.
- 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: version number proposal
Posted by Rafael Schloming <ra...@redhat.com>.
Aidan Skinner wrote:
>> I'm of two minds on this. On the one hand I think your proposal probably
>> most accurately reflects the reality of the current situation. On the other
>> hand, I don't think the current situation is really a great place for us to
>> be as a project.
>
> I think version numbers which reflect reality is probably a plus. I
> don't think it would be detrimental to the one team, one project, one
> qpid goal. There are definately issues there, but I don't think
> independently varying version numbers would add to those.
Part of my point is that the extent to which they reflect reality
depends on where you want things to be going.
One view is that JMS is API stable, and other clients are not, therefore
JMS gets a nice stable version number, and the other components don't.
However in some ways that's a bit missleading since we're not trying to
version the JMS API (we don't need to, it already has its own version
number), we're versioning our *implementation* of JMS, and to a much
greater extent the maturity of our *implementation* does depend on the
other pieces of the project, e.g. the broker, and the level of interop
with other clients, and one version number better reflects *that* reality.
>> In particular, one of the core goals of qpid is to provide a consistent
>> cross-language messaging experience, and that includes equivalently stable
>> and similar looking/feeling APIs across all the client languages we support.
>
> I'm not sure that similar looking/feeling APIs are really desierable.
> I'd rather see idiomatic APIs that feel comfortable and natural in the
> language than shoe-horning JMS into C++.
I'm not sure what would require shoe-horning. The JMS API is very
simple, and could easily be translated idiomatically into any of our
current client languages, e.g in ruby it would be quite possible to
model connection, session, producer, consumer, and message and yet still
have consumer.on_message {|m| blah ... } rather than
consumer.setMessageListener(...).
That said, my statement in no way implied that we should mindlessly
translate JMS into the other languages, simply that we need some set of
APIs that are at a similar level of abstraction such that they can each
support multiple protocols underneath.
> The fact of the matter is that the various clients and brokers are at
> differing levels of robustness, internal stability and API stability
> and that's not something that I really see changing anytime soon.
Actually at the moment I think they're all fairly close. There are
really only two outliers: JMS and dotnet. JMS being more API stable due
to being JMS, and dotnet being in an exceptional category at the moment
since we haven't really settled on how we're going to provide something
there in a sustainable manner going forward.
IMHO the appropriate way to make the situation with the JMS client clear
is to actually state on our download page that it is a JMS client, and
maybe even put JMS in the artifact name. This will have infinitely more
meaning than any version number choice.
As for dotnet, I think that probably deserves its own discussion, since
the issue there is really more about how we are going to maintain the
thing going forward, and less about what it's current version number
should be.
>> So for me, I'd either stick with the Mx version numbers, or use a pre 1.0
>> version numbering scheme until we've reached that goal of a consistent cross
>> language messaging experience, and only from there move into post 1.0
>> territory.
>
> I could buy into s/M/0./ for everything (but not s/M/1./). I know some
> people are opposed to releasing 0.x versions for marketing reasons,
> but that essentially removes any useful information from the rev.
I agree, and personally I don't think marketing should enter into the
version number discussion. I think once you let marketing in, you've
removed all hope for sane and useful version numbers. ;)
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: version number proposal
Posted by Aidan Skinner <ai...@gmail.com>.
On Tue, Feb 3, 2009 at 1:34 AM, Rafael Schloming <ra...@redhat.com> wrote:
> Aidan Skinner wrote:
[...]
>> I think we should adopt APR[1] style version numbers, they convey
>> meaningful information and are widely understood.
>>
>> As a result of this, I think we should have different version numbers
>> for the individual components. The C++ API, the Java API and the .Net
[...]
> I'm of two minds on this. On the one hand I think your proposal probably
> most accurately reflects the reality of the current situation. On the other
> hand, I don't think the current situation is really a great place for us to
> be as a project.
I think version numbers which reflect reality is probably a plus. I
don't think it would be detrimental to the one team, one project, one
qpid goal. There are definately issues there, but I don't think
independently varying version numbers would add to those.
> In particular, one of the core goals of qpid is to provide a consistent
> cross-language messaging experience, and that includes equivalently stable
> and similar looking/feeling APIs across all the client languages we support.
I'm not sure that similar looking/feeling APIs are really desierable.
I'd rather see idiomatic APIs that feel comfortable and natural in the
language than shoe-horning JMS into C++.
The fact of the matter is that the various clients and brokers are at
differing levels of robustness, internal stability and API stability
and that's not something that I really see changing anytime soon.
> Unfortunately, to date we haven't been particularly good at cross language
> coordination, and so in some respects the project starts to feel like
> several completely independent sub-projects. This of course makes it
> tempting to treat Qpid as a distro/umbrella project as you propose, but I
> can't help but feel that doing that is giving up on an important goal.
I don't think having seperate release numbers is giving up on that goal.
There are some obvious disconnects in the team regarding attitudes
towards things like backward API and ABI compatability, appropriate
levels of change at particular points in the release cycle etc. that
should be addressed, but it's a seperate issue IMHO.
> So for me, I'd either stick with the Mx version numbers, or use a pre 1.0
> version numbering scheme until we've reached that goal of a consistent cross
> language messaging experience, and only from there move into post 1.0
> territory.
I could buy into s/M/0./ for everything (but not s/M/1./). I know some
people are opposed to releasing 0.x versions for marketing reasons,
but that essentially removes any useful information from the rev.
- 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: version number proposal
Posted by Rajith Attapattu <ra...@gmail.com>.
On Tue, Feb 3, 2009 at 5:17 AM, Aidan Skinner <ai...@gmail.com>wrote:
> On Tue, Feb 3, 2009 at 2:05 AM, Rajith Attapattu <ra...@gmail.com>
> wrote:
>
> > Having gone through 5 releases and looking at the queries on the user/dev
> > list, my experience is that release by language has not quite worked.
>
> We're not doing release by language. We're doing releases of the whole
> codebase, some bits of which have lost the ability to talk to other
> bits over time. While that's certainly unfortunate, it's not something
> which slicing release by functional area is going to change. It's not
> a process issue, it's a decision about preserving compatability.
>
I agree that we release the whole codebase. Appologies for not explaining
what I meant by "release by language"
The point I was trying to highlight was that currently decesions about
interoperability/feature set/direction etc.. are determined by language
which is the root cause of the incompatibility between clients, brokers and
management tools.
I agree that slicing releases by functional area isn't going to change this
situation automatiocally. However if we are forced to think in terms of
brokers, clients and management tools, rather than java, c++,ruby,
python..etc then we can focus more on getting the clients, brokers and
management tools aligned in the same direction.
This is not going to happen overnight, but unless we break it down by
functional area and go in that direction it is not going to happen.
>
> > Instead we have ended up with a very confusing matrix in our download
> page
> > and this has confused potential users to no end.
>
> The matrix is really confusing, there's probably a clearer way to
> represent things.
>
Maybe, but I think a more saner approach is to slowly but surely get into a
position where we have very simple matrix.
>
> > As I have suggested in another thread I think we need to do component
> > releases in the future.
> > i.e Have separate downloads for broker/clients/management tools than one
> > monolithic file.
>
> I think having seperate downloads for each is a good plan.
>
> > When we move to such a model it makes sense (As Rafi suggested) to have a
> > common version number for brokers and one across all clients and one
> across
> > all management tools.
>
> This seems rather odd given that they're all at different levels of
> maturity, evolve indepenently of each other and really share very
> little in common other than functional area.
Totally agree and but I also believe this is not a good situation to be in.
Ideally the java broker and c++ broker should support the same AMQP versions
and more or less the same core feature set.
I am sure there will be certain features (ex LVQ or RDMA) in each broker
that will not be in the other, but atleast the core set of features should
be the same. I see we are making an effort to do that with things like ACL,
flow to disk etc.
This is not an easy task, but if we get there Qpid will be in a solid
position.
> To take management as an
> example, the JMX GUI, CLI and Qman are all at different stages and
> that's not even taking the QMF bits into account.
>
Thats exactly my point. Unless we have a clear mission/vision for each
functional area Qpid will remain as a collection of tools thats all over the
place.
I agree that as a new project that was growing rapidly it was kinda of
difficult to get everything alinged.
But going forward we should make a serious effort in alingning the
vision/goals of each functional area across all languages we support.
>
> > The above scheme will make it easy for potential users to make a clear
> > decision.
> > It also provides them with a clear path to upgrade and maintenance.
>
> A clear path to upgrade and maintenance would surely be to preserve
> compatability. I don't see how splitting releases into three broad
> functional areas makes any difference to this.
>
See my comments above.
>
> > P.S I also think that we need to organize our dir structure (as
> Rafi/Rob
> > pointed out) and the wiki as client/broker/management tools.
>
> This seems insane to me for the reasons outlined above.
Again this suggestion was keeping in mind the above goals.
>
>
> > Eventually a particular management tool should work with both java and
> c++
> > brokers. So it make sense to partition the wiki/documentation space by
> > component rather than language. Right now the wiki is by language and
> it's
> > kinda of all over the place.
>
> This does make more sense. Somewhere there's a freemind file with a
> reasonable hierarchy, and there's an old export organised something
> along those lines in branches/forrest-site. I ran out of steam on that
> and it's rotted a bit now though.
>
> - 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
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
Re: version number proposal
Posted by Aidan Skinner <ai...@gmail.com>.
On Tue, Feb 3, 2009 at 2:05 AM, Rajith Attapattu <ra...@gmail.com> wrote:
> Having gone through 5 releases and looking at the queries on the user/dev
> list, my experience is that release by language has not quite worked.
We're not doing release by language. We're doing releases of the whole
codebase, some bits of which have lost the ability to talk to other
bits over time. While that's certainly unfortunate, it's not something
which slicing release by functional area is going to change. It's not
a process issue, it's a decision about preserving compatability.
> Instead we have ended up with a very confusing matrix in our download page
> and this has confused potential users to no end.
The matrix is really confusing, there's probably a clearer way to
represent things.
> As I have suggested in another thread I think we need to do component
> releases in the future.
> i.e Have separate downloads for broker/clients/management tools than one
> monolithic file.
I think having seperate downloads for each is a good plan.
> When we move to such a model it makes sense (As Rafi suggested) to have a
> common version number for brokers and one across all clients and one across
> all management tools.
This seems rather odd given that they're all at different levels of
maturity, evolve indepenently of each other and really share very
little in common other than functional area. To take management as an
example, the JMX GUI, CLI and Qman are all at different stages and
that's not even taking the QMF bits into account.
> The above scheme will make it easy for potential users to make a clear
> decision.
> It also provides them with a clear path to upgrade and maintenance.
A clear path to upgrade and maintenance would surely be to preserve
compatability. I don't see how splitting releases into three broad
functional areas makes any difference to this.
> P.S I also think that we need to organize our dir structure (as Rafi/Rob
> pointed out) and the wiki as client/broker/management tools.
This seems insane to me for the reasons outlined above.
> Eventually a particular management tool should work with both java and c++
> brokers. So it make sense to partition the wiki/documentation space by
> component rather than language. Right now the wiki is by language and it's
> kinda of all over the place.
This does make more sense. Somewhere there's a freemind file with a
reasonable hierarchy, and there's an old export organised something
along those lines in branches/forrest-site. I ran out of steam on that
and it's rotted a bit now though.
- 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: version number proposal
Posted by Rajith Attapattu <ra...@gmail.com>.
Hi Aidan,
As Rafi pointed out, your proposal seems like a good fit to handle the
current situation.
However the current situation is very confusing for potential users and
newcomers to the project.
Having gone through 5 releases and looking at the queries on the user/dev
list, my experience is that release by language has not quite worked.
Instead we have ended up with a very confusing matrix in our download page
and this has confused potential users to no end.
If we continue down this path we will end up with a more confusing matrix of
client/broker versions (not mentioned the growing management tools).
As I have suggested in another thread I think we need to do component
releases in the future.
i.e Have separate downloads for broker/clients/management tools than one
monolithic file.
When we move to such a model it makes sense (As Rafi suggested) to have a
common version number for brokers and one across all clients and one across
all management tools.
This will enable the clients, brokers and the management tools to evolve
independently.
The above scheme will make it easy for potential users to make a clear
decision.
It also provides them with a clear path to upgrade and maintenance.
Regards,
Rajith
P.S I also think that we need to organize our dir structure (as Rafi/Rob
pointed out) and the wiki as client/broker/management tools.
Eventually a particular management tool should work with both java and c++
brokers. So it make sense to partition the wiki/documentation space by
component rather than language. Right now the wiki is by language and it's
kinda of all over the place.
On Mon, Feb 2, 2009 at 8:34 PM, Rafael Schloming <ra...@redhat.com> wrote:
> Aidan Skinner wrote:
>
>> On Mon, Feb 2, 2009 at 11:15 PM, Rafael Schloming <ra...@redhat.com>
>> wrote:
>>
>> I think this would make a bit more sense. For me at least versions like
>>> 1.5
>>> and 1.6 imply a level of API compatibility and client/server interop that
>>> goes beyond what we currently test for in our releases.
>>>
>>
>> I think we should adopt APR[1] style version numbers, they convey
>> meaningful information and are widely understood.
>>
>> As a result of this, I think we should have different version numbers
>> for the individual components. The C++ API, the Java API and the .Net
>> API are all rich APIs which vary independently of the protocol
>> version. The C++ client from M4 is not compatible with the version
>> from M3, but both implement 0-10. The python and ruby clients are much
>> lower level, and don't vary as much. The Java client primarily exposes
>> JMS and the API doesn't vary between M2, M3 and M4 despite adding
>> 0-10.
>>
>> Between M3 and M4 the C++ client API change would have required a
>> major revision bump. The java client didn't change in this way, so
>> would have had a minor bump. We'll quickly get into a situation where
>> the components have a variety of version numbers.
>>
>> To make it clearer what a release is, I propose a release revision.
>> Either a monotonically incrementing integer, such as we currently have
>> or an ISO-date. At this point Apache Qpid quite closely resembles an
>> OS distribution in terms of components brought together to form a
>> functional release. This model has worked well for those projects, and
>> I think it would work for us.
>>
>> As an example, M4+1 might be "Apache Qpid 5" or "Apache Qpid 2008.04"
>> and contain qpid-java-1.4.0, qpid-cpp-1.4.0 and qpid-python-1.4.0
>> M4+1+1 might be "Apache Qpid 6" and contain qpid-java-1.5,
>> qpid-cpp-2.0 and qpid-python-1.4.1. The main number is useful for
>> talking about the release to the outside world, the individual package
>> numbers are useful when trying to figure out what you might need to do
>> to make your application work with a new version of qpid.
>>
>
> I'm of two minds on this. On the one hand I think your proposal probably
> most accurately reflects the reality of the current situation. On the other
> hand, I don't think the current situation is really a great place for us to
> be as a project.
>
> In particular, one of the core goals of qpid is to provide a consistent
> cross-language messaging experience, and that includes equivalently stable
> and similar looking/feeling APIs across all the client languages we support.
> Unfortunately, to date we haven't been particularly good at cross language
> coordination, and so in some respects the project starts to feel like
> several completely independent sub-projects. This of course makes it
> tempting to treat Qpid as a distro/umbrella project as you propose, but I
> can't help but feel that doing that is giving up on an important goal.
>
> So for me, I'd either stick with the Mx version numbers, or use a pre 1.0
> version numbering scheme until we've reached that goal of a consistent cross
> language messaging experience, and only from there move into post 1.0
> territory.
>
> As an aside, this does remind me a bit of the perpetual directory layout
> conversation where someone (I think usually Rob) says that it would make
> more sense to split things up between the broker and the clients than to
> split things up by language. I think the same argument could be made for
> component versions as well, e.g. one shared version number across all the
> clients, and one for each broker. That division would certainly reflect the
> aforementioned goal.
>
> --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: version number proposal
Posted by Rafael Schloming <ra...@redhat.com>.
Aidan Skinner wrote:
> On Mon, Feb 2, 2009 at 11:15 PM, Rafael Schloming <ra...@redhat.com> wrote:
>
>> I think this would make a bit more sense. For me at least versions like 1.5
>> and 1.6 imply a level of API compatibility and client/server interop that
>> goes beyond what we currently test for in our releases.
>
> I think we should adopt APR[1] style version numbers, they convey
> meaningful information and are widely understood.
>
> As a result of this, I think we should have different version numbers
> for the individual components. The C++ API, the Java API and the .Net
> API are all rich APIs which vary independently of the protocol
> version. The C++ client from M4 is not compatible with the version
> from M3, but both implement 0-10. The python and ruby clients are much
> lower level, and don't vary as much. The Java client primarily exposes
> JMS and the API doesn't vary between M2, M3 and M4 despite adding
> 0-10.
>
> Between M3 and M4 the C++ client API change would have required a
> major revision bump. The java client didn't change in this way, so
> would have had a minor bump. We'll quickly get into a situation where
> the components have a variety of version numbers.
>
> To make it clearer what a release is, I propose a release revision.
> Either a monotonically incrementing integer, such as we currently have
> or an ISO-date. At this point Apache Qpid quite closely resembles an
> OS distribution in terms of components brought together to form a
> functional release. This model has worked well for those projects, and
> I think it would work for us.
>
> As an example, M4+1 might be "Apache Qpid 5" or "Apache Qpid 2008.04"
> and contain qpid-java-1.4.0, qpid-cpp-1.4.0 and qpid-python-1.4.0
> M4+1+1 might be "Apache Qpid 6" and contain qpid-java-1.5,
> qpid-cpp-2.0 and qpid-python-1.4.1. The main number is useful for
> talking about the release to the outside world, the individual package
> numbers are useful when trying to figure out what you might need to do
> to make your application work with a new version of qpid.
I'm of two minds on this. On the one hand I think your proposal probably
most accurately reflects the reality of the current situation. On the
other hand, I don't think the current situation is really a great place
for us to be as a project.
In particular, one of the core goals of qpid is to provide a consistent
cross-language messaging experience, and that includes equivalently
stable and similar looking/feeling APIs across all the client languages
we support. Unfortunately, to date we haven't been particularly good at
cross language coordination, and so in some respects the project starts
to feel like several completely independent sub-projects. This of course
makes it tempting to treat Qpid as a distro/umbrella project as you
propose, but I can't help but feel that doing that is giving up on an
important goal.
So for me, I'd either stick with the Mx version numbers, or use a pre
1.0 version numbering scheme until we've reached that goal of a
consistent cross language messaging experience, and only from there move
into post 1.0 territory.
As an aside, this does remind me a bit of the perpetual directory layout
conversation where someone (I think usually Rob) says that it would make
more sense to split things up between the broker and the clients than to
split things up by language. I think the same argument could be made for
component versions as well, e.g. one shared version number across all
the clients, and one for each broker. That division would certainly
reflect the aforementioned goal.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: version number proposal
Posted by Aidan Skinner <ai...@gmail.com>.
On Mon, Feb 2, 2009 at 11:15 PM, Rafael Schloming <ra...@redhat.com> wrote:
> I think this would make a bit more sense. For me at least versions like 1.5
> and 1.6 imply a level of API compatibility and client/server interop that
> goes beyond what we currently test for in our releases.
I think we should adopt APR[1] style version numbers, they convey
meaningful information and are widely understood.
As a result of this, I think we should have different version numbers
for the individual components. The C++ API, the Java API and the .Net
API are all rich APIs which vary independently of the protocol
version. The C++ client from M4 is not compatible with the version
from M3, but both implement 0-10. The python and ruby clients are much
lower level, and don't vary as much. The Java client primarily exposes
JMS and the API doesn't vary between M2, M3 and M4 despite adding
0-10.
Between M3 and M4 the C++ client API change would have required a
major revision bump. The java client didn't change in this way, so
would have had a minor bump. We'll quickly get into a situation where
the components have a variety of version numbers.
To make it clearer what a release is, I propose a release revision.
Either a monotonically incrementing integer, such as we currently have
or an ISO-date. At this point Apache Qpid quite closely resembles an
OS distribution in terms of components brought together to form a
functional release. This model has worked well for those projects, and
I think it would work for us.
As an example, M4+1 might be "Apache Qpid 5" or "Apache Qpid 2008.04"
and contain qpid-java-1.4.0, qpid-cpp-1.4.0 and qpid-python-1.4.0
M4+1+1 might be "Apache Qpid 6" and contain qpid-java-1.5,
qpid-cpp-2.0 and qpid-python-1.4.1. The main number is useful for
talking about the release to the outside world, the individual package
numbers are useful when trying to figure out what you might need to do
to make your application work with a new version of qpid.
- Aidan
[1] http://apr.apache.org/versioning.html [2]
[2] This is essentially kernel style, without the stable/unstable
connotations of odd/even releases.
--
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: version number proposal
Posted by Rajith Attapattu <ra...@gmail.com>.
I would agree with Rafi.
If we jump straightaway to 1.x and continue from there, people will start to
expect API compatibility.
I don't think Qpid is in a position to make such guarantee.
I also agree that we should not follow AMQP versions. Our version has to be
independent of AMQP.
BUT I think we should wait to do a Qpid 1.0 release until AMQP 1.0 .
Once AMQP settles down with 1.0 (and provide compatibility between minor
versions) it will make life easy for Qpid to maintain API compatibility for
python, ruby and c++. After that Qpid can do any amount of releases
independent of AMQP versions.
Regards,
Rajith
On Mon, Feb 2, 2009 at 6:15 PM, Rafael Schloming <ra...@redhat.com> wrote:
> Steve Huston wrote:
>
>> Hi Carl,
>>
>> Short and sweet... I propose we move from Mx naming and with M5 move to
>>> 1.5 then 1.6 and so forth.
>>>
>>> any takers?
>>>
>>
>> Another possibility... Go to 0.5, 0.6, etc. until a version is done
>> that supports AMQP 1.0 and that is Qpid 1.0.
>>
>
> I think this would make a bit more sense. For me at least versions like 1.5
> and 1.6 imply a level of API compatibility and client/server interop that
> goes beyond what we currently test for in our releases.
>
> --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: version number proposal
Posted by Rafael Schloming <ra...@redhat.com>.
Steve Huston wrote:
> Hi Carl,
>
>> Short and sweet... I propose we move from Mx naming and with
>> M5 move to 1.5 then 1.6 and so forth.
>>
>> any takers?
>
> Another possibility... Go to 0.5, 0.6, etc. until a version is done
> that supports AMQP 1.0 and that is Qpid 1.0.
I think this would make a bit more sense. For me at least versions like
1.5 and 1.6 imply a level of API compatibility and client/server interop
that goes beyond what we currently test for in our releases.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: version number proposal
Posted by Steve Huston <sh...@riverace.com>.
Hi Carl,
> Short and sweet... I propose we move from Mx naming and with
> M5 move to 1.5 then 1.6 and so forth.
>
> any takers?
Another possibility... Go to 0.5, 0.6, etc. until a version is done
that supports AMQP 1.0 and that is Qpid 1.0.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org