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:17:53 GMT
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.

> 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


Mime
View raw message