Wicket Stuff Core Release Process

We try and release once per month and as soon as possible following each wicket release.

If there hasn't been a wicket release we will release a point release on the current stable branch.

Sometimes there is a divergence in the API between the current wicket snapshot and the stable release. In this case we will try to revert commits to allow the build to work but if that doesn't work we will just wait until the next upstream release.

Steps to create New Version

Preliminaries:

We are assuming that the core-1.4.x pom.xml has a version of 1.4-SNAPSHOT and we are going to be creating the 1.4.15 release.

Make sure that your ~/.m2/settings.xml contains your credentials to deploy to https://oss.sonatype.org:

<server>
         <id>sonatype-nexus-staging</id>
         <username>YourUserName</username>
         <password>yourPasswd</password>
</server>

First we set the start point on the current 1.4 trunk:

git checkout core-1.4.x

Second we create a local branch to stage the stable release into.

git checkout -b core-1.4.15 core-1.4.x

Third we edit the pom.xml and change <wicket.version> in the properties section to be 1.4.15.

Fourth we change the '''scm''' section url to point at the tag that will be created for this release. e.g.

<scm>
<url>https://github.com/wicketstuff/core/tree/wicketstuff-core-1.4.15</url>

Fifth we change all of the pom versions to be 1.4.15:

mvn -DnewVersion=1.4.15 versions:set
mvn -DnewVersion=1.4.15 versions:commit

Sixth we check if there are any snapshot dependencies:

find . -name pom.xml | while read POM; do grep -H SNAPSHOT $POM; done;

There will be some matches because there are projects that are currently disabled. We are interested in modules that are reachable with SNAPSHOT artifacts present (they need to either be fixed if possible or commented out).

Seventh we build the release artifacts and stage them through oss.sonatype.org:

A) Build the core pom.xml artifact

mvn -DperformRelease=true [-Dgpg.passphrase=yourGpgPassPhrase] -N clean deploy
...
[INFO] Not executing Javadoc as the project is not a Java classpath-capable package
[INFO] [gpg:sign {execution: sign-artifacts}]
GPG Passphrase: *******
....

B) Then the Java 5 artifacts:

cd jdk-1.5-parent
JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun MAVEN_OPTS=-Xmx512m mvn [-Dgpg.passphrase=yourGpgPassPhrase] -DperformRelease=true deploy
...
[INFO] Not executing Javadoc as the project is not a Java classpath-capable package
[INFO] [gpg:sign {execution: sign-artifacts}]
GPG Passphrase: *******
....

C) Then the Java 6 artifacts:

cd jdk-1.6-parent
JAVA_HOME=/usr/lib/jvm/java-6-sun MAVEN_OPTS=-Xmx512m mvn [-Dgpg.passphrase=yourGpgPassPhrase] -DperformRelease=true deploy
...
[INFO] Not executing Javadoc as the project is not a Java classpath-capable package
[INFO] [gpg:sign {execution: sign-artifacts}]
GPG Passphrase: *******
....

Eight we close the staging repository and check that everything was uploaded properly using the oss.sonatype.org release account.

• A : Click on the Staging Repositories Link.
• B : Observe the two (2) rows deployed by you. One for the Java 5 compiled artifacts and the other is for the Java 6 compiled artifacts.
• C : Check both repository check boxes and then click on Close to close the staging repositories.
• D : In B if you select a row (not the url part) you can expand this section to check the uploaded content.

• In the first phase of closing a repository you assign a comment message that is emailed to the other repository users.
• This screen shows the second phase where the closing process is taking place. If there are problems with the structure of the pom or versions it will be detected here and the close operation will fail.

Ninth we commit any changes to the local core-1.4.15 stable branch and tag the release:

git commit -a
git tag -s wicketstuff-core-1.4.15 -m "wicketstuff-core-1.4.15 release tag"

Enter your GPG phass phrase to sign the tag using the same key used for the release

Tenth we push the release tag into github

git push origin wicketstuff-core-1.4.15

Creating the release message.

We let git shortlog do the heavy lifting of what changed between the new-release-tag and the old-release-tag.

git shortlog -n old-release-tag..new-release-tag

For example the changes between 1.4.17 and 1.4.17.1 can be extracted as:

git fetch origin --tags
git shortlog wicketstuff-core-1.4.17..wicketstuff-core-1.4.17.1

Inaiat Henrique (2):
      [meiomask] mootools meiomask wicket 1.4x
      [meiomask] added mootols meiomask module to pom

Isammoc (1):
      Merged pull request #25 from lambdadaku/core-1.4.x.

Michael O'Cleirigh (3):
      datatable-autocomplete: add styling and selection capabilities.
      datatable-autocomplete: add highlight selected row capability.
      commit wicketstuff-core 1.4.17.1 release pom's

Nick Wiedenbrueck (3):
      [console] backport to core-1.4.x
      [console] removed onInitilize for extension
      Merge branch 'core-1.4.x' into console-1.4.x

cretzel (3):
      [console] fixing build dependencies
      [console] fixing hibernate driver class
      [console] remove java 6 dependencies

lambdadaku (1):
      Added multiple controls and map types (adapted to latest google maps     2)     - controls: 3d Zoom Control, hierarchical, navlabel, and overview map     - map types: physical, aerial, and aerial 3d

seb (5):
      wicket-shiro, wicket-minis: (license header, serialVersionUID, javadoc)
      ServerHostNameAndTimeFilter backport
      Merge branch 'refs/heads/core-1.4.x' of ssh://[email protected]/wicketstuff/core.git into HEAD
      updated change log
      minis: code cleanu

Getting the list of new modules

git log --name-status --diff-filter=A wicketstuff-core-1.4.17..wicketstuff-core-1.4.17.1

Then we look for new top level directories being created and add then to the release message if found.