All,

Just a reminder for myself, and for some discussion: the following
steps were taken to build wicket-6.0.0-beta2, provided that everything
builds and works of course (I hit a snag with the archetype)

 - start gpg-agent as daemon
 - pull changes
 - checkout master
 - update release notes+commit
 - mvn release:branch -DbranchName=build/wicket-6.0.0-beta2 (fill in
the new development versions)
 - git checkout build/wicket-6.0.0-beta2
 - update the archetypes/quickstart/src/main/achetype-resources/pom.xml
to use to be released version of Wicket
 - mvn release:prepare (fill in 6.0.0-beta2 for all but atmosphere,
new dev version doesn't matter, see next step)
 - git reset HEAD^ --hard so that HEAD points to the 6.0.0-beta2
release, not the new dev version
 - git archive --format=tar.gz --prefix=apache-wicket-6.0.0-beta2/ -o
apache-wicket-6.0.0-beta2.tar.gz wicket-6.0.0-beta2
 - git archive --format=zip --prefix=apache-wicket-6.0.0-beta2/ -o
apache-wicket-6.0.0-beta2.zip wicket-6.0.0-beta2
 - gpg --armor --detached-sig --use-agent --sign
apache-wicket-6.0.0-beta2.tar.gz
 - gpg --armor --detached-sig --use-agent --sign apache-wicket-6.0.0-beta2.zip
 - gpg --print-md SHA1 apache-wicket-6.0.0-beta2.tar.gz >
apache-wicket-6.0.0-beta2.tar.gz.sha
 - gpg --print-md MD5 apache-wicket-6.0.0-beta2.tar.gz >
apache-wicket-6.0.0-beta2.tar.gz.md5
 - gpg --print-md SHA1 apache-wicket-6.0.0-beta2.zip >
apache-wicket-6.0.0-beta2.zip.sha
 - gpg --print-md MD5 apache-wicket-6.0.0-beta2.zip >
apache-wicket-6.0.0-beta2.zip.md5
 - git tag -s --force wicket-6.0.0-beta2 to sign the tag (overwrites
the maven generated tag)
 - ssh people.apache.org mkdir public_html/wicket-6.0.0-beta2
 - scp apache-wicket-* people.apache.org:public_html/wicket-6.0.0-beta2
 - git push origin build/wicket-6.0.0-beta2:refs/heads/build/wicket-6.0.0-beta2
 - git push -tags origin

The thing left to do:
 - mvn deploy

Most of this is scriptable, especially up til mvn release:prepare.
Then we need input for the versions, and Maven doesn't support our
numbering format. Probably we need to generate the release.properties
ourselves. Another thing that might be less perfect for scripting is
the gpg-agent.

I also don't like the idea of having to reset HEAD^ after the
release:prepare step, but the maven invocations baffle me with what
options are going to do what I want: not prepare for the next
development release.

Martijn

Reply via email to