qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: [Discussion] Release Artefacts
Date Wed, 18 Feb 2009 18:19:02 GMT
Martin Ritchie wrote:
> 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.

Personally I don't think pre-generating the framing provides any value 
at all. In fact quite the opposite. If you apply a patch that modifies 
any of the templates and try to rebuild, you'll be in a world of hurt.

I believe the reason the C++ source code includes pre-generated framing 
is actually to avoid adding a build dependency on ruby, but since the 
Java framing generator adds no external dependencies at all, I think it 
would be a step backwards to introduce what would essentially amount to 
a crippled source tarball.


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

View raw message