This works nicely for me, but I want to clarify the steps. Tell me what I'm getting wrong:
On the 0.30 release branch: 1. mvn versions:set versions:commit -DnewVersion=0.30-beta 2. mvn -P apache-release deploy 3. Revert the changes from step 1 in my checkout, leaving things at 0.30-SNAPSHOT The closest thing to documentation for this procedure I was able to find was this: https://cwiki.apache.org/confluence/display/qpid/Proton+Release+Steps#ProtonReleaseSteps-ProducingBinaryArtifacts Justin On Thu, Aug 7, 2014 at 12:09 PM, Robbie Gemmell <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 > >> > > > > >
