qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marnie McCormack <marnie.mccorm...@googlemail.com>
Subject Re: version number proposal
Date Tue, 03 Feb 2009 12:27:49 GMT
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 <rafaels@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
>
>

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