qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aidan Skinner <aidan.skin...@gmail.com>
Subject Re: version number proposal
Date Tue, 03 Feb 2009 10:02:10 GMT
On Tue, Feb 3, 2009 at 1:34 AM, Rafael Schloming <rafaels@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


Mime
View raw message