qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: 0.30 release update - alpha is available
Date Thu, 07 Aug 2014 21:37:42 GMT
On 7 August 2014 20:18, Justin Ross <jross@apache.org> wrote:

> On Wed, Aug 6, 2014 at 9:04 AM, Robbie Gemmell <robbie.gemmell@gmail.com>
> wrote:
>
> > I still havent got round to using the output, but inspecting the
> structure
> > of whats there I had a few comments (that unfortunately got really long
> > :P).
> >
> > The Short Version:
> >
> > - We need to start building the QMF2 bits.
> >
>
> As you note below, this needs a bit more work from a release standpoint.
>  Right now it produces four different jars.
>

Thats atually as expected, the individual jars will get deployed to Nexus
(and then eventually Central) but the build also produces two tar.gz files
(which will also be deployed) for the main components that are the release
assemblies we could ship via the website, one for the broker plugin and one
for the tools(inc gui) pieces:

qpid-qmf2-tools/target/qpid-qmf2-tools-0.30-SNAPSHOT-bin.tar.gz
qpid-broker-plugins-management-qmf2/target/qpid-broker-plugins-management-qmf2-0.30-SNAPSHOT-bin.tar.gz

The things needing done are to finalise the README/LICENCE/NOTICE stuff,
and prevent a 'source release' archive being created for the whole
directory. I'll look at at least the later in the morning as well, but
neither should pevent proceeding with the beta since we wont actually be
releasing the staged artifacts and the repo will just get dropped once each
RC comes round.


>
> > - Do we need a duplicate java source artifact?
> >
>
> To start, I'm fine removing it.  It's easy either way.
>
> However, I want to argue well for what I consider its merits.  I don't
> recall participating in the original debate.
>
>  - Java is the oddball here.  Almost everything else has its own source
> tarball.
>

True, though I dont think they should have really, until we start releasing
them independently and those archives actually become 'the release' for
those components, which they currently arent really.

Whilst there are certainly benefits to having them, I think one of the
reasons which essentially forced the situation of the original cpp specific
archive is that the Java tree was huge due to historically containing
binary libs. I wouldnt remove what is already there but I would resist
adding more duplication for now, instead focusing on your later point of
having independently releaseable modules, which would entirely remove the
problem.


>  - To a point, It's nice for people to be able to get what they want and
> just what they want, without downloading a bunch of other stuff.
>

I completely agree. This is the reason we ship separate binaries for all
the individual Java components rather than only a single overall binary (an
archive I am particularly happy will no longer exist, it was a mess).


>  - The java source tarball on offer corresponds directly to the java build
> system entry point, making it one cohesive source module.
>

This is indeed true (mostly, there are things you can do to make the build
reference out to the specs dir, but it doesnt do that by default anymore
since I committed the code it was always generating from those files, and
that can certainly be stopped entirely).


> If duplication is the chief concern,


Its certainly a concern but its not the main concern, see next bit.


> I'd personally be more in favor of
> getting rid of the "full release" tarball and simply point folks at
> subversion for that.


We can only do that once we stop it actually being 'the release'. From an
Apache point of view that archive is currently what constitutes our 'Qpid
release' and so is really what we vote on, with the other archives
(particularly the binaries) being conveniences.

We can certainly start to release e.g. the C++ or Java bits independently
in their own archives, with their own associated votes, removing those bits
from the overall archive until the point it no longer exists.


>  I'd add that I favor the move to  independently
> releasable modules, and I'd love to see that happen as soon as we're all
> ready (I am).
>
> Justin
>

I'm also in favour, its one of the reasons I did the initial work on the
maven build, we just arent quite at the end state yet since its still all
being released 'as one'. I was planning to bring this point up again myself
once our first release using the new maven build was out the way.

Robbie

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