Release Procedures
Release Procedures
Get newest source from Github
Prerequisites
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
https://github.com/statsbiblioteket
Then do
git clone git@github.com:statsbiblioteket/PROJECT-NAME-HERE
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:
<version>1.3</version>
replace it with
<version>1.3.1-SNAPSHOT</version>
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:
vi CHANGELOG.md
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
src/main/config
and documentation should be found in
README.md
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
Run
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
Prerequisites
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
Run
mvn release:perform
This should run without errors and upload the commit to nexus.
Push commits to Github
Run
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:
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.