Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (athena.apache.org: domain of robbie.gemmell@gmail.com
 designates 209.85.217.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANVjZ_SUpygmim9mh0+hvqf-AjBQpTLsxGJUES60_HpVnrtmwQ@mail.gmail.com>
References: 
 <CANVjZ_SUpygmim9mh0+hvqf-AjBQpTLsxGJUES60_HpVnrtmwQ@mail.gmail.com>
Date: Wed, 6 Aug 2014 14:04:07 +0100
Message-ID: 
 <CAFitrpRbmw5yz5yg5+3VMWhu93omoWHB2D1r_2OkbFqmrfLGUA@mail.gmail.com>
Subject: Re: 0.30 release update - alpha is available
From: Robbie Gemmell <robbie.gemmell@gmail.com>
To: "users@qpid.apache.org" <users@qpid.apache.org>
Content-Type: multipart/alternative; boundary=001a11c221ae838a4004fff59bbf

--001a11c221ae838a4004fff59bbf
Content-Type: text/plain; charset=UTF-8

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.
- Do we need a duplicate java source artifact?
- We should use appropriate versions and the apache-release profile for
Beta/RCs to deploy sources jars etc release artifacts to a staging repo.


The Unfortunately Long Version:

The maven build I added for the QMF2 bits Fraser did isn't being run yet,
we should add that. It lives at
http://svn.apache.org/repos/asf/qpid/trunk/qpid/tools/src/java and needs to
be built after the main build is installed. This reminds me there is still
some final polish suff mentioned in the TODO file that needs done before
final release.

Do we want a qpid-java-$release.tar.gz source archive? It was discussed
years ago that it would be good not to have duplicate source release
artifacts, and this would add a new one. I understand the reasons the
cpp-specific source artifact came to exist {deleted to shorted :P] but I'm
not sure I see the need for a java-specific source release before such a
time as those bits are released independently and it becomes a necessity.
At that point the build would then produce+publish this itself, whereas
currently it explicitly suppresses creation of the source release assembly
that the Apache parent pom would normally make when using the
"apache-release" maven profile (and it now occurs to me, the QMF2 build
ought to be doing so as well and probably isnt) because the official
release is the existing 'full release' archive.

For the maven local install tree, the "org/apache/qpid/" subtree contains
all of our output. The rest is simply transitive dependencies for maven
itself and any plugins the building/testing uses, so there is no real need
to upload. Once we start issuing Beta/RC's there arguably isnt a need to
upload any of it explicitly, as the needed output should really be deployed
directly to a Nexus staging repo by running "mvn deploy" (yay, no more
manual seperate publication step). Following slightly from earlier, we we
will want to use the "apache-release" profile when doing the deploy in
order to create+deploy sources jars, javadoc jars, and sign the artifacts
before deploying them.

This is where we might hit some process'y issues as the way we have tended
to release all the components in the past, creating an all-containing
release branch and immediately update to the release version but then
taking weeks/months for it to actually be released, doesnt entirely jive
with how maven projects are often released, where the branch will often be
skipped straight for a tag, only contain the maven modules being released,
and may even be created/managed by the maven build itself using e.g. the
scm or release plugin, which can handle the versions as well. The main
issue is going to be around versions. It would be good to continue
publishing widely available 0.30-SNAPSHOT artifacts right until the release
actually goes out. However, we also really want to test the full release
process during the RC stages (which some projects might not really have,
instead using snapshots for that purpose to a large extent, or
widely-publishing their RCs as releases) which really means deploying the
complete 'proposed final' style artifacts to a staging repo rather than the
normal subset to the snapshots repo. In order to deploy to a staging repo
rather than the snapshots repo the artifacts will need a release version
since snapshot versioned artifacts will automatically be deployed to the
snapshots repo. I would quite like to avoid the prolonged intermediate use
of the 0.30 release version on the release branch though, i.e using 0.30
over and over for beta+RC1+RC2+RC3 with perhaps 0.30-SNAPSHOT inbetween to
allow for publishing snapshots. I think the nicest thing is that we
actually version the components 0.30beta, 0.30rc1 etc at each stage and use
0.30-SNAPSHOT inbetween, only progressing to actually use 0.30 when the
next spin really is the intended release. There are maven plugins that can
update the pom versions for you, on-the-fly without if desired, so we can
use those to change the versions easily.

I'm sure few will get this far without skipping the above, but if you didnt
skip: sorry, it was meant to be a quick mail :D

Robbie

On 21 July 2014 20:59, Justin Ross <jross@apache.org> wrote:

> Hi, everyone.  Alpha is now available:
>
>   Release artifacts:
> https://dist.apache.org/repos/dist/dev/qpid/0.30-alpha/
>   Release tool log output:
> http://people.apache.org/~jross/qpid-trunk-2014-07-21.log
>   Maven local install:
> http://people.apache.org/~jross/maven-trunk-2014-07-21/
>
> Note that the java artifacts have changed.  First, I'm using the new
> artifacts generated by the maven build system (those are the ones ending in
> -bin.tar.gz).  Second, qpid-java-$release.tar.gz is now a pure source
> archive, suitable for use with the Java Build How To wiki page.
>
> Please take a look and let me know if the new outputs are acceptable.
>
> Thanks,
> Justin
>
> ---
> 0.30 release page:
> https://cwiki.apache.org/confluence/display/qpid/0.30+Release
>

--001a11c221ae838a4004fff59bbf--