qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Ross <jr...@apache.org>
Subject Re: 0.30 release update - alpha is available
Date Thu, 07 Aug 2014 19:01:54 GMT
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 <robbie.gemmell@gmail.com>
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 <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