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 20:47:06 GMT
Assuming you have your ~/.m2/settings.xml configured [1] with your
credentials, the only thing thing I see in your command is that you have a
space before the profile name, which I wouldnt normally do and offhand dont
know whether it is supported...<goes to try>...

Ah, so the space seems ok, but it still went bang, which is what I assume
you saw too. They have changed the rules for acceptable JavaDoc at some
point, and obviously nobody has created ours since. Ok, some editing
required; I'll do that first thing in the morning. I'll also look into
adding a profile (or see if we can skip the signing from the apache-release
profile) so we can do this on the CI jobs and ensure it doesnt catch us out
again.

Some of this procedure wont necessarily be documented because as I
mentioned in my earlier mail it is a little unusual, due to our release
process in general and then more so due to the maven bits only being
subsets of the overall release currently. For example, the release guidance
at http://www.apache.org/dev/publishing-maven-artifacts.html follows a
method many (but certainly not all) maven-using projects will in its use
the maven-release-plugin to drive things, however we couldnt really do the
same if we wanted because the java dir does not constitute the entire
release (I'm ignoring the possibility of putting poms further up the tree
before anyone mentions it :P).

Finally, because some of the systests can be a litle racey at times, and
the maven build is not as forgiving of this as the old build was, I would
suggest you run the tests separately and then skip them while doing the
deploy, to avoid needing to drop the staging repo and begin from scratch if
a test does fail.

Robbie

[1] If you dont, you'll need to add something like the below, filling in
your credentials. To avoid plain text passwords, see
http://maven.apache.org/guides/mini/guide-encryption.html

<settings>
  <servers>
    <server>
      <id>apache.snapshots.https</id>
      <username> ... </username>
      <password> ... </password>
    </server>
    <server>
      <id>apache.releases.https</id>
      <username> ... </username>
      <password> ... </password>
    </server>
  </servers>
</settings>


On 7 August 2014 20:01, Justin Ross <jross@apache.org> wrote:

> 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