Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

NOTE: these instructions are for the Roller 5.0 branch and with Roller 5.1 (yet to be released) these instructions will change.

1.

...

Check out the Apache Roller source code from the appropriate branch.  Within the pom files, update the Roller version number to what you will be releasing (for example, 5.0.4-SNAPSHOT to 5.0.4).  Update the version within the sign*.sh file(s) in the root (5.0.x) or assembly-release (5.1.x) folder to that version as well.

2.  (5.0.x only) Create release for Tomcat and Java EE

The commands below will create the Roller for Tomcat release bundle in ZIP and Gzipped TAR formats and the ASCii signature files:

Code Block
   ./build-tomcat-release.sh
   ./sign-tomcat-release.sh

Once done, move the six files (tar/gz/source & .asc for them) outside of weblogger-assembly/target folder (otherwise, those files will be lost in the Java EE build in the next step).

The commands below will create the Roller for Java EE release bundle in ZIP and Gzipped TAR formats and the ASCii signature files:

Code Block
   ./build-javaee-release.sh
   ./sign-javaee-release.sh

After that, four files (tar/gz & .asc for them) will be in the weblogger-assembly/target directory.

3. (5.1.x only) Create single release

From the Roller root folder, run mvn clean install.  Next, navigate to the assembly-release folder and run mvn clean install again.  Then run sign-release.sh.  In the assembly-release/target folder of the latter you'll have a total of eight files that need uploading:  two ZIP and two tar.gz files for the source and binary and the .gz.asc that will need to be uploaded.  For now, the distributions contain Open Office (ODT) formatted guides.  However, open them up within Open Office and export them as PDFs: name-of-guide-{roller release version}.pdf.  We'll place PDFs in the "docs" folder of the distribution (Step #5).

 

For any build, if you haven't already, you will also need to upload your public key to the KEYS file in the Roller distribution folder.  This has to be done only once for Roller no matter how many releases you make.  First use "gpg --list-keys" to determine the 8 character key ID for your key, and then make an ASCII armored key for it and add it to the MIT public key server.  For the SVN KEYS file, do an empty checkout of the folder (to avoid downloading the several large artifacts in this folder's hierarchy) and then an individual file svn update to get just the KEYS file, add your public key to it using the instructions at the top of the file, and then commit the KEYS file back:

Code Block
svn co https://dist.apache.org/repos/dist/release/roller --depth=empty
cd roller
svn update KEYS
(add public key to KEYS)
svn commit KEYS -m "Added my key to KEYS file."

For the Roller distribution KEYS file, do an ssh to <your apache user id>@people.apache.org, navigate to the /dist/roller folder, and use vi or another command line tool to add your KEY to that file.  (For vi, go to the end of the file by entering a capital G followed by a small o to enter edit mode, then paste your key in, followed by an Escape key and a :wq to save the file.)

4. Check In Version changes

Do an SVN commit of the changes you did in Step #1.  Then, add a release candidate tag using the svn copy command, for example:

Code Block
svn copy https://svn.apache.org/repos/asf/roller/branches/roller_5.0  https://svn.apache.org/repos/asf/roller/tags/roller_5.0.4-rc1
or
svn copy https://svn.apache.org/repos/asf/roller/trunk  https://svn.apache.org/repos/asf/roller/tags/roller_5.1.0-rc1

5. Move artifacts to Roller Dist - Dev folder and Vote on release

We use svnpubsub for our distribution releases (docs).  We upload the artifacts to the dist/dev/roller folder (using svn add) when we hold the vote.  After the vote is approved use an svn move to move the artifacts to the dist/release/roller folder.  As the dist/dev and dist/release folders have countless artifacts from all the other Apache projects, use the SVN --depth=empty commands below to check out just the Roller folders, as shown in the following SVN commands:

...

 Create a stable branch for the release
Name the branch with the format roller-{version}, e.g. roller-5.2.0
2. Update version numbers
You will need to change the version numbers in at least the files below:
    pom.xml
    app/pom.xml
    assembly-release/pom.xml
    assembly-release/sign-release.sh
    it-selenium/pom.xml
    it-selenium/src/test/resources/roller-jettyrun.properties
    docs/roller-install-guide.odt
    docs/roller-user-guide.odt
    docs/roller-install-guide.odt
3. Build Roller
Run a full build & test with "mvn install". If tests fail, you need to figure out why and rectify.
    $ mvn install
4. Build the release package
Change directory into the assembly-release directory and do a Maven build there: "mvn package"
    $ cd assembly-release
    $ mvn package
5. Sign the release
Before you can do this, you need to have GPG setup and a key in place for signing releases. To sign the release, you can use the sign-release.sh script in the assemly-release directory like so:
    $ ./sign-release.sh
6. Make the release available

...

You make the release available by committing it to a Subversion (SVN) repo at 

...

...

...

. Get that repo and take a look at the directory structure there. If you are creating a Release Candidate (RC) then it will go into a subdirectory of the "dev" directory and if you are making a final release, then it must go into the "release" directory.
For example a 5.2.0 RC1 release would go into ./

Use svn add & svn commit to place the artifacts in the dev/roller/roller-5/v5.?/src, /docs, and /bin folders, similar to that done for earlier releases.

Call for a release vote on the DEV list and once the release is approved, move to the next step.  This file's JIRA list of solved Bugs, Improvements, etc. can be obtained from the "Road Map" JIRA tab, selecting the desired version's Release Notes, and then the Configure Release Notes button (choose Text output).  If there are any not-yet-publicized security issues that the patch fixes, don't mention them in that public email but do so instead on the separate Roller private (PMC-only) list. 

6. Move release files into place

Do an svn (remote) move of the dist/dev/roller/roller-5/v?.?.? folder to the dist/release/roller/roller-5 directory.  With this change the dev directory should be empty.  From the release/roller folder, do an svn rm of older releases from the same branch and of older, no-longer-supported branches as a result of the new release.  (Older releases are already archived elsewhere by the infrastructure team.) Wait up to 24 hours for mirrors to update.

As these files are huge it is considerably faster to move the files remotely on the SVN server instead of doing a local svn move followed by an SVN commit of those files back to the server, for example:

...

dev/roller/roller-5.

...

2/v5.2.0-rc-1

...

Another example, a final 5.2.0 release would go into ./release/roller-5.

...

2/v5.2.0

7. Update the website to point to the new files

Update the website's download and sidebar links in SVN and publish them.

8. Announce the release, update branch version

Make the announcement on the mailing list and other places, and update the branch to the next snapshot version (e.g., 5.0.4 to 5.0.5-SNAPSHOT).  Update the JIRA as explained at the bottom of the Apache CXF release management page.