Skip to content
This repository has been archived by the owner on Sep 15, 2023. It is now read-only.

Release HOWTO

Pieter Pauwels edited this page Aug 29, 2020 · 11 revisions

Introduction

This page describes how to do a release of IFCtoRDF. As we are using pure Maven for build lifecycle management, it is drop dead easy :0). So hold on to your hats, here we go!

N.B. BEFORE RELEASING THIS PROJECT, YOU SHOULD ALWAYS CHECK IF YOU HAVE DEFINED THE MOST RECENT VERSION OF pipauwel/EXPRESStoOWL, the version can be obtained from Maven Central.

Details

First, checkout a fresh version of the ENTIRE IFCtoRDF Github repository

It is pretty small and this saves time later on. The following command can be used:

% git clone https://github.com/pipauwel/IFCtoRDF.git

You may also be prompted for your password here.

Make sure you're on the right branch (master)

% git checkout master

Check/Update CHANGES.md

Please ensure that the details in CHANGES.md are accurate.

You can see a list of issues tagged for a given release via this URL (update the version number), note that all issues should be closed at this stage... as they should have been resolved.

https://github.com/pipauwel/IFCtoRDF/milestone/1?closed=1

Then edit the header for the top-most list of changes (which will say something like "Current Development 0.2-SNAPSHOT (yyyy-mm-dd)") to have the correct release number and date, and commit that change.

Check formatting

mvn java-formatter:format

then commit if necessary.

Generate Release Javadoc

In all of the steps below, replace X.Y with the actual release number.

% git checkout master
% vim pom.xml (change project version from X.Y-SNAPSHOT to X.Y)
% git commit -a -m "staging release"
% git push
% mvn javadoc:javadoc
% mkdir -p tmp/javadoc/X.Y/
% cp -r target/site/apidocs/ tmp/javadoc/X.Y/

% git checkout gh-pages
% git pull
% vim pom.xml (change project version from X.Y-SNAPSHOT to X.Y - potentially copy from master branch: git checkout master pom.xml)
% vim changes.md (update changes - potentially copy from master branch: git checkout master CHANGES.md)
% mv tmp/javadoc/* .
% git add X.Y/
% git commit -a -m "X.Y Release Javadoc"
% git push
% git checkout master
% mvn clean 

Prepare the Release Artifacts (Dry-Run)

% vim pom.xml (change project version from X.Y to X.Y-SNAPSHOT)
% git commit -a -m "temp update to snapshot version X.Y-SNAPSHOT"
% git push
% rm -rf ~/.m2/repository/com/github/pipauwel/IFCtoRDF
% mvn release:clean release:prepare -DdryRun=true 

Executing the above makes life a breeze for us. It does the following:

  • cleans out all previous release-related module directories
  • prepares us for a release, stating that this is a dryRun of the actual release. This gives us the opportunity to review the artifacts.

At this stage is it imperative to check the resulting artifacts as we wish to iron out any discrepancies.

Commit to Git & Tag

We now do the release proper.

% mvn release:clean release:prepare 

N.B. If the final command fails this may be due to non-interactive mode being activated in your local Git client. This can easily be overcome by explicitly passing in the -Dusername=${username} -Dpassword=${password} arguments to the command.

This will create and commit the release tag and bump the development version in the pom.xml file.

Build & Deploy to Sonatype

This will build the pom, jar, javadoc, signatures and sources, and push them to the Sonatype staging repository

% mvn release:perform 

If this command fails, ensure that you have the sonatype server configuration within your ~/.m2/settings.xml as follows

<settings>
  <servers>
  ...
    <server>
      <id>sonatype-nexus-staging</id>
      <username>${nexus_username}</username>
      <password>${nexus_password}</password>
    </server>
  ...

Close the Sonatype Staging Repository

% Browse to [https://oss.sonatype.org/index.html] and log in.
% Navigate to the Staging Repositories side tab and locate the stating release.
% 'Close' (by clicking on the correct row in the table representing the artifact you want to release) the repository so that others can view and review it.
% Once you have reviewed it, 'Release' it (by clicking on the correct row in the table representing the artifact you want to release).

Update CHANGES.md

Create a new "current release" block at the top of the file, which will say something like:

Current Development 0.2-SNAPSHOT (yyyy-mm-dd)

And then commit this to the master branch.

Publicize

Post to the relevant lists... e.g. https://www.w3.org/community/lbd/

Please report any issues with this workflow to lewis dot mcgibbney at gmail dot com