Release management

This page describes how to create and deploy the SIS Maven artifacts, binary bundle, javadoc and list of API changes. The Release FAQ page describes the foundation wide policies. Instructions on this page describe the steps specific to SIS (we do not use the mvn release command). The intended audiences are SIS release managers.

Configure

Before to perform a release, make sure that the following conditions hold:

  • Commands will be executed in a Unix shell.
  • Git, Subversion, GNU GPG, ZIP, Maven, Ant, Java and the Java compiler are available on the path.
  • The release management setup steps have been executed once.

For all instructions in this page, $OLD_VERSION and $NEW_VERSION stand for the version number of the previous and the new release respectively, and $RELEASE_CANDIDATE stands for the current release attempt. Those versions shall be set on the command line like below (Unix):

gpg --list-keys                     # For getting the value to put in <your key ID>
unset PATH_TO_FX
export OLD_VERSION=0.8
export NEW_VERSION=1.0
export RELEASE_CANDIDATE=1
export SIGNING_KEY=<your key ID>    # hexadecimal number with 8 or 40 digits.

Directory layout

The steps described in this page assume the following directory layout (some directories will be created as a result of the steps). Any other layout can be used. However if the layout differs, then the relative paths in this page shall be adjusted accordingly.

<any root directory for SIS>
├─ $NEW_VERSION-RC
├─ master
├─ non-free
│  └─ sis-epsg
├─ releases
│  ├─ distribution
│  │  └─ $NEW_VERSION
│  │     └─ RC$RELEASE_CANDIDATE
│  └─ integration-test
│     └─ maven
└─ site
   └─ content
      └─ apidocs

Review project status before branching

Replace the $OLD_VERSION number by $NEW_VERSION in the values of following properties on the development branch:

  • DOWNLOAD_URL in application/sis-console/src/main/java/org/apache/sis/console/ResourcesDownloader.java file.
  • <sis.non-free.version> in root pom.xml file.
  • Review the README and NOTICE files in root directory.
  • Review the README files in application/sis-console/src/main/artifact/ and subdirectories.

If not already done, build the C/C++ code of sis-gdal module:

cd storage/sis-gdal/src/main/c
make
cd -

Commit and merge with other branches up to master.

git add --update
git commit --message="Set version number and the EPSG geodetic dataset URL to expected values after release."
# merge with master

Before to start the release process, we need to test more extensively the master. The tests described below often reveal errors that were unnoticed in daily builds. It is better to detect and fix them before to create the release branch. First, ensure that a PostgreSQL server is running and listening to the default port on local host (optional but recommended for more exhaustive testing — see PostgreSQL testing configuration for more details). Then execute the following commands and fix as much warnings as practical:

systemctl start postgresql.service        # Optional — exact command depends on Linux distribution.
mvn clean install --define org.apache.sis.test.extensive=true
mvn javadoc:aggregate

If the SIS_DATA environment variable was set during above build, unset it a try again. Ideally the build should be tested in both conditions (SIS_DATA set and unset). That test may be done in a separated shell (console window) in order to preserve the variable value in the shell performing the release.

unset SIS_DATA
echo $SIS_DATA
mvn test

Update the list of supported CRS

The following steps regenerate the CoordinateOperationMethods and CoordinateReferenceSystems pages. Those steps are also useful as additional tests, since failure to generate those pages may reveal problems.

  1. Open the AuthorityCodes class, search DEPRECATED=0 (it appears in a SQL fragment) and replace by (DEPRECATED=0 OR TRUE). Do not commit! This is a temporary hack for including deprecated codes in the CRS list to be generated. Those codes will appear with strike for making clear that they are deprecated.
  2. Open the CoordinateOperationMethods Java class and execute its main method, for example in an IDE.
  3. Open the CoordinateReferenceSystems Java class and execute its main method.
  4. If successful, HTML files will be generated in the current directory. Open those files in a web browser and verify that information are okay, in particular the SIS and EPSG version numbers in the first paragraph.
  5. If okay, move those two HTML files to the ../site/content/tables/ directory, overwriting previous files.
  6. Revert the hack in AuthorityCodes class.
  7. Commit: svn commit --message="Update the list CRS and operation methods supported by Apache SIS $NEW_VERSION."

Prepare release notes

We update JIRA soon because doing so is sometime a reminder of uncompleted tasks in source code. Update JIRA tasks and prepare release notes as below:

  • Ensure that the Fix Version in issues resolved since the last release includes this release version correctly.
  • Ensure that all open issues are resolved or closed before proceeding further.
  • On the site source code repository, create a content/release-notes/$NEW_VERSION.html file with all the features added.
  • Use content/release-notes/$OLD_VERSION.html as a template, omitting everything between the <body> and </body> tags.
  • The release notes can be obtained from JIRA, by clicking on the Versions tab → the version number → Release notes and then configuring the release notes to display HTML format and copying it. A suggested approach would be to reorganize the release notes as New Features, then Improvements, then Bug Fixes, then Tests and finally Tasks. The Sub Tasks can be classified according the category of their parent issue.

Commit to staging area (not published immediately):

cd ../site
cp content/release-notes/$OLD_VERSION.html content/release-notes/$NEW_VERSION.html
# Edit release notes before to continue.
svn add content/release-notes/$NEW_VERSION.html
svn commit --message "Release notes for Apache SIS $NEW_VERSION."

Create release branch

Execute the following commands. It is okay to checkout the branch in a separated directory if desired. The SIS_RC_DIR environment variable will specify that directory.

cd ../master
git checkout -b $NEW_VERSION-RC
cd $NEW_VERSION-RC
export SIS_RC_DIR=`pwd`

Remove the modules that are not yet ready for a release. This may require removing <module> elements in the parent pom.xml file.

git rm core/sis-cql
git rm core/sis-portrayal
git rm storage/sis-shapefile
git rm application/sis-javafx
git rm application/sis-webapp
git rm storage/sis-storage/src/main/java/org/apache/sis/storage/WritableGridCoverageResource.java
git add --update    # for the removal of <module> elements in pom.xml files.
git commit --message="Remove the modules to be excluded from $NEW_VERSION release."

Open the root pom.xml file in an editor and perform the following changes:

  • Remove the whole <pluginRepositories> block (including comment), since it should not be needed for releases (and is actually not allowed).
  • Remove the jetty dependency since the module that used it has been removed.

We need to update the SIS version numbers not only in the pom.xml files, but also in a few Java files. The following command performs the replacement using Ant.

ant -buildfile core/sis-build-helper/src/main/ant/prepare-release.xml branch -Dsis.version=$NEW_VERSION
git rm core/sis-build-helper/src/main/ant

Validate with git diff, search SNAPSHOT in the whole source directory in case we missed some, then commit:

git add --update
mvn clean install
git commit --message="Set version number to $NEW_VERSION."

Maybe apply the following hacks on the release branch only (do not apply them on master). Check first if those hacks are still needed for the next release (they were needed for 1.0):

  • Remove all use of javax.annotation.Generated annotation. This removal should not have any effect on compilation result.
  • In the root pom.xml under maven-javadoc-plugin configuration, add the following elements:
    • <link>http://sis.apache.org/apidocs</link> inside <links> block.
    • <additionalOption>-Xdoclint:all,-reference</additionalOption> inside <additionalOptions> block.
  • Commit on the release branch only.

Test branch extensively

Build the project with the apache-release profile enabled. This profile performs the following actions:

  • Enable extensive tests (i.e. it will set the org.apache.sis.test.extensive property to true).
  • Generate Javadoc. This may fail if the source code contains invalid Javadoc tags or broken HTML.
  • Generate additional binary artifacts (*.zip and *.oxt files). This will fail if duplicated class files or resources are found. Consequently building the *.zip file is an additional test worth to do before deployment.
  • Sign the artifacts.

Each of those additional products may cause a failure that did not happen in normal builds.

mvn clean install --activate-profiles apache-release
find . -name "sis-*.asc" -exec gpg --verify '{}' \;     # Verify signatures.

More the target directory and execute all examples documented in the command-line interface page with the sis command replaced by the following:

java -classpath "binaries/*" -enableassertions org.apache.sis.console.Command

Prepare non-free resources

Go to the directory that contains a checkout of https://svn.apache.org/repos/asf/sis/data/non-free/sis-epsg. Those modules will not be part of the distribution (except on Maven), but we nevertheless need to ensure that they work. Replace occurrences of <version>$OLD_VERSION</version> by <version>$NEW_VERSION</version> in the pom.xml files.

cd ../non-free
svn update
mvn clean install
mvn javadoc:javadoc                   # Test that javadoc can be generated.
svn commit --message "Set version number and dependencies to $NEW_VERSION."

Integration test

Open the root pom.xml file of integration tests. Set version numbers to $NEW_VERSION without -SNAPSHOT suffix. Verify the configuration and version of Maven plugins. Then test and commit (note that execution may be slow).

cd ../distribution/integration-test
svn update
cd maven
mvn clean test
svn commit --message "Set version number and dependencies to $NEW_VERSION."

Deploy Maven artifacts

If above verifications succeeded, performs the following temporary changes (to be discarded after the deployment to Maven repository):

  • Remove temporarily the sis-openoffice module from application/pom.xml.
  • Remove the test-jar goal from maven-jar-plugin in the root pom.xml.
  • Remove all SIS dependencies declared with <type>test-jar</type> in all pom.xml files. This hack will force us to skip test compilations.

Then deploy SIS (without test JAR files). Deploy also the non-free resources in a staging repository separated from the rest of Apache SIS. If there is any issue with this deployment, the staging repository can easily be dropped and recreated.

cd $SIS_RC_DIR
mvn clean deploy --activate-profiles apache-release --define maven.test.skip=true
cd ../non-free
mvn clean deploy --activate-profiles apache-release

Verify and close the Nexus release artifacts

Verify the staged artifacts in the Nexus repository. The artifacts can be found under Build PromotionStaging repositories, and searching for org.apache.sis in the Repository column. Navigate through the artifact tree and make sure that all javadoc, source and jar files have .asc (GPG signature) and .md5 files. Select any *-javadoc.jar file and click on the Archive Browser tab on the right side. Select any *.html file which is known to use some of the custom taglets defined in the sis-build-helper module. Click on that file and verify that the custom elements are rendered properly. In particular, all Java code snippets are missing if the @preformat taglet had not be properly registered, so try to see at least one code snippet.

Additional cleaning:

  • Delete all org/apache/sis/parent/$NEW_VERSION/parent-$NEW_VERSION-source-release.zip.* files on the Nexus repository. They should not be there - source release will be deployed on an other repository later.

Close the Nexus staging repository:

  • Click the checkboxes for the open staging repositories (org.apache.sis-<id>) and press Close in the menu bar.
  • In the description field, enter "SIS $NEW_VERSION-RC$RELEASE_CANDIDATE" (replace $NEW_VERSION and $RELEASE_CANDIDATE by appropriate values. This will not be done automatically since this field box is not our bash shell!).
  • Click on the org.apache.sis-<id> link in order to get the URL to the temporary Maven repository created by Nexus.

We will announce later (in the Put the release candidate up for a vote section) on the dev@ mailing list the availability of this temporary repository for testing purpose.

In the Nexus repository used for non-free resources:

  • Delete all *-source-release.zip.* files since they duplicate the *-source.zip.* files.
  • In the sis-epsg-$NEW_VERSION.jar file, verify that META-INF/LICENSE contain the EPSG terms of use.
  • Close the repository and take note of its URL.

Test the Nexus release artifacts

Go to the test Maven project. Open the root pom.xml file and set the <version> number to the SIS release to be tested. Then go to the <url> declaration of the first <repository> and replace value by the URL of the temporary Maven repository created by Nexus. Usually, only the 3 last digits need to be updated.

cd ../releases/integration-test/maven
# Edit <url> in pom.xml before to continue.
mvn compile
svn commit -m "Test project for SIS $NEW_VERSION-RC$RELEASE_CANDIDATE"

Create a temporary directory where Apache SIS will write the EPSG dataset.

mkdir target/SpatialMetadata
export SIS_DATA=`pwd`/target/SpatialMetadata

Clear the local Maven repository in order to force downloads from the Nexus repository, then test. This will also verify the checksums.

rm -r ~/.m2/repository/org/apache/sis
mvn package --strict-checksums

Verify that the EPSG dataset has been created, then cleanup:

ll $SIS_DATA/Databases/SpatialMetadata
mvn clean

Stage the source, binary and javadoc artifacts

Generate the Javadoc:

cd $SIS_RC_DIR
git checkout .            # Discard local changes, in particular the hack for excluding test files.
mvn clean install --activate-profiles apache-release
mvn javadoc:aggregate
cd target/site
zip -9 -r apache-sis-$NEW_VERSION-doc.zip apidocs
cd ../..

Initialize the distribution directory

Create the directory for the new version and release candidate within the distribution directory. The $RELEASE_CANDIDATE variable shall be the number of current release attempt.

cd ../releases/distribution
svn update
mkdir -p $NEW_VERSION/RC$RELEASE_CANDIDATE
svn add $NEW_VERSION
cd $NEW_VERSION/RC$RELEASE_CANDIDATE
export DIST_DIR=`pwd`

Copy the HEADER.html file from the previous release. Update the file content if necessary.

svn copy https://dist.apache.org/repos/dist/release/sis/$OLD_VERSION/HEADER.html .

Move the files generated by Maven to the distribution directory:

mv $SIS_RC_DIR/target/sis-$NEW_VERSION-* .
mv $SIS_RC_DIR/target/site/apache-sis-$NEW_VERSION-* .
mv $SIS_RC_DIR/target/distribution/apache-sis-$NEW_VERSION.zip .

Rename the files to something more conform to the convention seen in other Apache projects:

mv apache-sis-$NEW_VERSION.zip             apache-sis-$NEW_VERSION-bin.zip
mv sis-$NEW_VERSION-source-release.zip     apache-sis-$NEW_VERSION-src.zip
mv sis-$NEW_VERSION-source-release.zip.asc apache-sis-$NEW_VERSION-src.zip.asc

Sign and commit

Sign the source, javadoc and binary artifacts:

shas512um apache-sis-$NEW_VERSION-src.zip > apache-sis-$NEW_VERSION-src.zip.sha
md5sum    apache-sis-$NEW_VERSION-src.zip > apache-sis-$NEW_VERSION-src.zip.md5

gpg --armor --detach-sign --default-key $SIGNING_KEY apache-sis-$NEW_VERSION-doc.zip
sha512sum apache-sis-$NEW_VERSION-doc.zip > apache-sis-$NEW_VERSION-doc.zip.sha
md5sum    apache-sis-$NEW_VERSION-doc.zip > apache-sis-$NEW_VERSION-doc.zip.md5

gpg --armor --detach-sign --default-key $SIGNING_KEY apache-sis-$NEW_VERSION-bin.zip
sha512sum apache-sis-$NEW_VERSION-bin.zip > apache-sis-$NEW_VERSION-bin.zip.sha
md5sum    apache-sis-$NEW_VERSION-bin.zip > apache-sis-$NEW_VERSION-bin.zip.md5

Verify checksums and signatures:

find . -name "*.md5" -exec md5sum    --check '{}' \;
find . -name "*.sha" -exec sha512sum --check '{}' \;
find . -name "*.asc" -exec gpg      --verify '{}' \;

Commit:

svn add apache-sis-$NEW_VERSION-*
cd ../..
svn commit --message "SIS release candidate $RELEASE_CANDIDATE"

Update online Javadoc

Copy the Javadoc to the web site staging directory:

cd ../site/content
rm -r apidocs
unzip $DIST_DIR/apache-sis-$NEW_VERSION-doc.zip

Execute svn add for new files and svn remove for deleted files:

cd apidocs
svn status | gawk '/^\?.*/ {print $2}' | xargs svn add
svn status | gawk '/^\!.*/ {print $2}' | xargs svn remove
svn commit --message "Update javadoc for SIS $NEW_RELEASE."

Test the release

Execute the following commands in any temporary directory for testing the sources:

wget https://dist.apache.org/repos/dist/dev/sis/$NEW_VERSION/RC$RELEASE_CANDIDATE/apache-sis-$NEW_VERSION-src.zip \
     https://dist.apache.org/repos/dist/dev/sis/$NEW_VERSION/RC$RELEASE_CANDIDATE/apache-sis-$NEW_VERSION-src.zip.asc
# Test
gpg --verify apache-sis-$NEW_VERSION-src.zip.asc
unzip apache-sis-$NEW_VERSION-src.zip
cd sis-$NEW_VERSION
mvn install

Execute the following commands in any temporary directory for testing the binary:

wget https://dist.apache.org/repos/dist/dev/sis/$NEW_VERSION/RC$RELEASE_CANDIDATE/apache-sis-$NEW_VERSION-bin.zip \
     https://dist.apache.org/repos/dist/dev/sis/$NEW_VERSION/RC$RELEASE_CANDIDATE/apache-sis-$NEW_VERSION-bin.zip.asc
# Test
gpg --verify apache-sis-$NEW_VERSION-bin.zip.asc
unzip apache-sis-$NEW_VERSION-bin.zip
cd apache-sis-$NEW_VERSION
unset SIS_DATA
bin/sis about --verbose
bin/sis metadata https://github.com/opengeospatial/geoapi/raw/master/geoapi-netcdf/src/test/resources/org/opengis/wrapper/netcdf/NCEP-SST.nc
bin/sis crs http://svn.apache.org/repos/asf/sis/trunk/core/sis-referencing/src/test/resources/org/apache/sis/referencing/crs/ProjectedCRS.xml --format WKT

Prepare OpenOffice add-in

The OpenOffice add-in source code can be distributed under Apache 2 license only. But the binary may contain non-free resources, notably the EPSG geodetic dataset. For now, the release manager should apply the following local modifications before to build the add-in:

  • Move to the application/sis-openoffice directory.
  • Replace the src/main/unopkg/license.txt file by EPSG terms of use. A copy is found in the non-free group of SIS modules.
  • Run mvn package --activate-profiles non-free.

Prepare Web site

Review and update the content/DOAP.rdf file on the site source code repository. Add a new <release> block for the new release with the estimated release date.

Update the version numbers from the old one to $NEW_VERSION in the following files.

  • content/index.mdtext
  • content/gdal.mdtext
  • content/downloads.mdtext (need also to update $NEW_VERSION-SNAPSHOT to the next snapshot version)
  • content/command-line.mdtext
  • content/epsg.mdtext (be aware that the version number may sometime be behind the SIS version number)

Commit:

svn commit --message "Prepare documentation for the $NEW_VERSION release."

The new web site will be published in the staging area. It will not yet be published on http://sis.apache.org.

Put the release candidate up for a vote

  • Create a VOTE email thread on dev@ to record votes as replies. A template is available here.
  • Create a DISCUSS email thread on dev@ for any vote questions. A template is available here.
  • Perform a review of the release and cast your vote:
  • a -1 vote does not necessarily mean that the vote must be redone, however it is usually a good idea to rollback the release if a -1 vote is received. See Recovering from a vetoed release below.
  • After the vote has been open for at least 72 hours, has at least three +1 PMC votes and no -1 votes, then post the results to the vote thread:
    • Reply to the initial email and prepend to the original subject "[RESULT]"
    • Include a list of everyone who voted +1, 0 or -1.

Recovering from a vetoed release

Reply to the initial vote email and prepend to the original subject:

[CANCELED]

Delete the svn tag created by the release:perform step:

svn delete https://svn.apache.org/repos/asf/sis/tags/$NEW_VERSION --message "deleting tag from rolled back release"

Drop the Nexus staging repository:

  • Go to Nexus repositoryBuild PromotionStaging repositories and search for org.apache.sis in the Repository column.
  • Right click on the closed staging repositories (org.apache.sis-<id>) and select Drop.

Make the required updates that caused the vote to be canceled during the release cycle.

Finalize the release

The artificats in the repository are not yet mirrored and available for Maven to download. Promote the staged Nexus artifacts, by releasing them.

  • Go to Nexus repositoryBuild PromotionStaging repositories and search for org.apache.sis in the Repository column.
  • Click the checkboxes of the closed staging repositories (org.apache.sis-<id>) and press Release in the menu bar.

Check in the source and binary artifacts into distribution svn which will be pulled by all mirrors within 24 hours. The dist/dev svn is not mirrored, but the dist/release is. From any directory:

svn move https://dist.apache.org/repos/dist/dev/sis/$NEW_VERSION/RC$RELEASE_CANDIDATE \
         https://dist.apache.org/repos/dist/release/sis/$NEW_VERSION \
    --message "Committing SIS Source and Binary Release Candidate $RELEASE_CANDIDATE for SIS-$NEW_VERSION."

svn delete https://dist.apache.org/repos/dist/dev/sis/$NEW_VERSION \
    --message "Delete SIS $NEW_VERSION staging repository after release."

Update JIRA:

  • Update the JIRA versions to mark the version as "released".
  • Set the date to the date that the release was approved.
  • Prepare for the next release:
    • Make a new release entry in JIRA for the next release.
    • Update the Roadmap wiki page.

Verify release signatures

Download all source and binary artifacts into a new directory, then execute in that directory:

find . -name "*.asc" -exec gpg --verify '{}' \;

The output shall report only good signatures.

Announce the release

  • WAIT 24 hours after committing releases for mirrors to replicate.
  • Publish the web site updates:
  • Make an announcement about the release on the dev@, users@, and announce@ mailing lists. A template is available here. The email needs to be sent from an @apache.org email address.

Delete the prior version:

svn delete https://dist.apache.org/repos/dist/release/sis/$OLD_VERSION \
    --message "Archive SIS-$OLD_VERSION after release of SIS-$NEW_VERSION."

Update master for the next development cycle

On the development branch (usually JDK8), update the version numbers in the pom.xml files on master with the following command:

mvn clean
mvn release:update-versions --define autoVersionSubmodules=true

This change will need to be merged manually on the JDK7 branch and on the master. Then on the development branch:

  • Edit the version number in the application/sis-console/src/main/artifact/README file.
  • Edit the value of the MAJOR_VERSION or MINOR_VERSION constant in the core/sis-utility/src/main/java/org/apache/sis/internal/system/Modules.java file.

Delete old artifacts on Maven snapshot repository

Login in the Nexus repository. In the Repositories tag, select Snapshots of type hosted (not to be confused with Snapshots of type group). Navigate to the org/apache/sis directory and delete all directories starting with the old version number. The sub-directories need to be cleaned too.