qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: version number proposal
Date Tue, 03 Feb 2009 15:40:44 GMT
On Tue, Feb 3, 2009 at 5:17 AM, Aidan Skinner <aidan.skinner@gmail.com>wrote:

> On Tue, Feb 3, 2009 at 2:05 AM, Rajith Attapattu <rajith77@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/

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