Release Procedures

Get newest source from Github


You have a github account and are registered as a developer in the Statsbiblioteket account. You have registered you ssh key at Github.

If you don't already have a checkout of the sources

Find them at

Then do

git clone

Your sources will now be in a folder with the same name as the project.

If you already have a checkout of the sources

Do a

git status

Make sure you have no uncommitted or unpushed changes. Then do

git pull

to get newest sources from Github. Handle any merges that might be needed.

Check out the correct branch

Make sure you are in the root directory of your source checkout.

Releasing from master

In most cases we release from the master branch:

git checkout master

Creating a maintenance release branch

However, if we do hotfixes or maintenance releases for an older release, we will do it for a branch for that release.

To create this branch, do

git tag

This will list all tags for the project.

And find the tag you want to branch from. Then do

git checkout YOUR_TAGNAME_HERE -b YOUR_TAGNAME_HERE-maintenance

This will create a branch from that tag, with the same name as the tag.

Immediately edit the pom.xml file, e.g.

vi pom.xml

Add .1-SNAPSHOT to the end of the version string. E.g. if the version was:


replace it with


Add, commit and push the changes.

You can now merge in commits from the master branch

Using an existing maintenance branch

If the maintenance branch already exists, just do


git checkout YOUR_TAGNAME_HERE-maintenance

You can now merge in commits from the master branch

Update changelog

Find changes since last commit using

git log

Then update the changelog and make sure it lists these changes:


Newer versions are at the top of the changelog.

Make sure embedded documentation and configuration is correct

Check that bundled configuration files and documentation is still correct for the new version.

Configuration files should be found in


and documentation should be found in

or referenced from there.

Do a clean build

To check the code builds, run

mvn clean verify

There should be no errors.

Run Maven Release plugin - prepare


mvn release:prepare

You will be prompted to resolve SNAPSHOT dependencies if there are any.

For each SNAPSHOT dependency, you need to resolve, whether you should use:

  • The previous released version - if so replace e.g. 1.7-SNAPSHOT with 1.6
  • The next released version - if so replace e.g. 1.7-SNAPSHOT with 1.7 (this assumes it has been released - otherwise you need to release that dependency first)

For the development version, you should usually use the next SNAPSHOT version after the one you release with - e.g if you release with a dependency of 1.7, set the development version to 1.8-SNAPSHOT

You will also be prompted for which version number you wish to use for release, in development and in tagnames. Accept the defaults.

EXCEPTION: When we do a major release version, bump e.g. 1.7-SNAPSHOT to 2.0 on release and 2.1-SNAPSHOT in development.

Run Maven Release Plugin - perform


You have added sbforge nexus to you maven settings, and are allowed to upload to sbforge nexus.

Your pom contains information about git repository and (usually thorugh a parent pom) maven repository (nexus) 

Perform the release


mvn release:perform

This should run without errors and upload the commit to nexus.

Push commits to Github


git push

to push commits to Github

Create wikipage

Create a page with information about the release, following the same template as e.g. this page:

Batch Structure Checker - release 1.9

Autonomous components are all subpages to this page:

Autonomous Components

Other components are subpages to this page:


Send package to IT Operations

 Send an email referring to the wiki page to IT Operations.

Ask them to install it to the stage system.

It may be helpful to visit their office and talk about the package.


  • No labels