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 16:09:24 GMT
Hi Justin,

To follow up on the versioning,

This plugin looks like a good fit:
http://mojo.codehaus.org/versions-maven-plugin/

The short variant of the command would be:
mvn versions:set versions:commit -DnewVersion=0.30

If using the above we should perhaps define a plugin-management entry in
our pom to lock the plugin version down, as it will use the latest
otherwise, though given all its going to do here perhaps that is ok. The
fully qualified command specifying the plugin version instead would be:
mvn org.codehaus.mojo:versions-maven-plugin:2.1:set
org.codehaus.mojo:versions-maven-plugin:2.1:commit -DnewVersion=0.30

Robbie

On 6 August 2014 14:04, 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.
> - 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
>>
>
>

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