qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Ritchie <ritch...@apache.org>
Subject [Discussion] Release Artefacts
Date Wed, 18 Feb 2009 16:41:29 GMT
Hello,

I thought it best if we discuss what we are looking to release as
artefacts for the upcoming release.

Let me start with what I think we should be releasing with my reasons
and we can see what the general view is.

Starting with the source packages that we should be providing:

 - C++
 - C#
 - Java (broker, client, common & testing)
 - Java Management (all management components)
 - Ruby
 - Python

I believe that if we are providing source packages then they should
provide more value than a tar of the svn tree. Such is the case for
the C++ source that has had the framing already generated. I think the
frame generation should be performed for all of the source builds that
we provide this would mean that we do not need to bundle the various
generators and end users would have all the source they need. If a
user wanted to have control over the generated files then they can
download the tagged source version. I don't think mirroring a straight
svn export offers anything to an end user over the svn tag for the
release.

I am also suggesting that we split the Java AMQP implementation,
broker, client, common & tests from the Java management code as the
groups are distinct packages. Splitting the source down further to a
broker, client & common packages is not necessary.


In addition to the source packages we should also be providing binary
builds or at least access to builds of the components that we believe
are ready for use. I would also advocate that the packages we provide
should be of a useful unit to an end user. As such I would suggest the
following packages:
The current brokers should be shipped in the following packages:
 - C++ with a link by supported platform (32/64bit)
  + Linux, (binary/rpm/link)
  + Windows (zip/link)
 - Java (zip)

The brokers should be provided on their own without any other package
as that makes a useful package size for the following reasons:
1) Use of a Qpid broker with a client library that is not of the same
language or even a Qpid client
2) Upgrade of an existing Qpid broker, where clients are also not migrating.
3) Evaluation of Qpid brokers compared to other AMQP offerings.

Shipping the brokers on their own means that we can have discrete
client packages per language which allows them to be more readily used
with any AMQP broker.
Each of the clients (C++, DotNet, Java, Python, Ruby) could make up
two packages:
  + Client Libraries
  + Examples

I'd advocate the separation of library and examples as each package is
a useful package in its own right. I am more open here to persuasion
that this is unnecessary but thinking wider that just Qpid our clients
could be useful to all AMQP implementations. In these cases shipping
examples as a separate package makes sense to me.

Finally we have the management tools, apologies if I have missed a
tool from the list. Each of the tools should get their own package so
an end user can grab the tool they are interested in. Taking the steps
to make each of these tools a separate package opens the option for
them to release bug fixes in their own right without being tied to a
full release.

Management
 - Eclipse JMX Console
   + Win
   + Linux
   + OS X
 - JMX Command LIne Tool
 - QMan
 - WsDmAdapter


I'd like to get views from everyone in the project as it affects all
of the work we do and the way it is provided to the world. While it
may require a bit of effort to get the packages easily built for
release I think it is a worthwhile goal.

Cheers

Martin

-- 
Martin Ritchie

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org


Mime
View raw message