Release procedure

This section covers the steps of the release procedure. For the rest of this section, ${RELEASE_VER} is the next release version (that we are about to release), ${NEW_DEV_VER} is the next development version, and ${FUTURE_RELEASE_VER} is a future release version that immediately follows ${RELEASE_VER}.

Every milestone is named according to a VDM2C release version. By convention, the milestone corresponding to ${RELEASE_VER} is named v${RELEASE_VER}.

Note that in order to perform a release you must have login access to Aarhus University's (AUs) public build server.

Closing the current milestone

Before releasing ${RELEASE_VER} the corresponding milestone, v${RELEASE_VER}, must be closed. To do that, go to the list of milestones and close v${RELEASE_VER}. Afterwards, go to the issue tracker and update all issues to milestone ${FUTURE_RELEASE_VER}. When that's done the progress of milestone v${RELEASE_VER} will change to 100% since no open issues are associated with this milestone anymore.

Generate the release notes

The next step is to generate the ${RELEASE_VER} release notes. To do that, go to the release folder and execute the gen-release-notes.py script:

vdm2c $ cd release/
vdm2c/release $ ./gen-release-notes.py 

This script generates release notes for closed milestones based on a template (ReleaseNotes-template.md). So assuming that v${RELEASE_VER} has been closed then this script will generate the file ReleaseNotes_${RELEASE_VER}.md. Now, open ReleaseNotes_${RELEASE_VER}.md and add a description of the release.

Note that the directory also contains the release notes for previous VDM2C releases:

vdm2c/release $ ls release
./release/gen-release-notes.py
ReleaseNotes_0.0.10.md
ReleaseNotes_0.0.12.md
ReleaseNotes_0.0.14.md
ReleaseNotes_0.0.16.md
...
ReleaseNotes-template.md

Now, commit the release notes:

vdm2c/release $ git add ReleaseNotes_${RELEASE_VER}.md
vdm2c/release $ git commit -m "Add VDM2C ${RELEASE_VER} release notes"

Setting the release version and the next development version

Before performing the release, the release version and the next development version must be set by updating overture.release.properties, which is located in the root of the repository:

Release version = ${RELEASE_VER}
New development version = ${NEW_DEV_VER}-SNAPSHOT

Now, commit/push your overture.release.properties changes:

vdm2c $ git add overture.release.properties
vdm2c $ git commit -m "Prepare release of VDM2C ${RELEASE_VER}"
vdm2c $ git push

Performing the release

AUs public build server is configured to run a script that performs most of the release tasks. To perform the release go to the build server and execute the vdm2c-release build job. This will automatically generate and upload the VDM2C plugin to a publicly accessible p2 repository (see the installation instructions). Once the build job has completed you'll notice that the build server has added a tag, Release/v${RELEASE_VER}, to the commit that marks the release.

Finally, by convention the master branch must always point to latest release:

vdm2c $ git checkout master
vdm2c $ git merge Release/v${RELEASE_VER}
vdm2c $ git push

Publish the release on Github

The last step is to publish the release on Github. To do that, go to releases and draft a new release by following the instructions. Specifically, set the tag that marks the release (Release/v${RELEASE_VER}), add the content of the release notes (ReleaseNotes_${RELEASE_VER}.md) and upload a zip file that contains the contents of the p2 repository. This zip file is generated by the AU build server and is available at http://overture.au.dk/vdm2c/master/repository/p2.zip immediately after the vdm2c-release build job has finished. If you're in doubt then check the contents of previous published releases.

That's it - you're done!