Skip to content

SWEET Release HOWTO

Jump to bottom
brandonw edited this page Jul 14, 2022 · 11 revisions

Purpose and intended audience

This document is purposed for SWEET release managers. It was originally compiled by Lewis John McGibbney and recently updated by Brandon Whitehead. The document is based off of the official Github release documentation.

Introduction

The SWEET release procedure is not a difficult process but it is structured. The document provides all the resources, commands, etc. required to prepare and make the release and ensure that the community know what is going on along the way. It is encouraged for release managers to be familiarized with the terminal such that they can execute commands remotely.

Preparation

Ensure that all issues which have been worked on within the current release cycle are labeled with the appropriate version e.g. 3.5.0. This will ensure that we can generate an accurate release report which will forever be associated with the release you are about to make.

If no release label currently exists then merely create one from within milestones and label each issue/pull request with the label. Whilst you are doing this, you should also create a new milestone for the next development drive. Once you have done this assign all pending/open issues (if any exist) for the milestone you are trying to release to this new milestone. This can be done by

  • navigating to the milestones page,
  • clicking on the current milestone you wish to release,
  • click the box to highlight all open issues,
  • assign them to the new milestone (next development drive) you created above

Check all owl:versionInfo statements are consitent

Next, make sure that the owl:versionInfo entry within each file appropriately matches the release version you are trying to make. (This hasn't been an issue for some time, but best to quickly verify now.) As there are over 200 files one can automate this by running:

$ cd sweet/src
$ grep owl:versionInfo *.ttl

output should be something similar to:

humanAgriculture.ttl:                         owl:versionInfo "3.5.0" .
humanCommerce.ttl:                            owl:versionInfo "3.5.0" .
humanDecision.ttl:                            owl:versionInfo "3.5.0" .
...

Run robot reasoning

The purpose here is to check that the ontology is not incoherent. This will become more valuable as SWEET is further axiomatized. You can therefore run robot as follows

$ robot reason --reasoner ELK \
    --create-new-ontology-with-annotations true \
    --exclude-tautologies structural \
    --input sweetAll.ttl \
    --output sweetAll_ROBOT_results.ttl

You should check the output and generated file for any inconsistencies, errors and the like.

For reference, ROBOT has excellent documentation.

Tag the release

Creating an annotated tag in Git is simple. The easiest way is to specify -a when you run the tag command:

$ git tag -a v3.6.0 -m "SWEET version 3.6.0"

Then push your tag to remote origin

$ git push origin v3.6.0
Counting objects: 1, done.
Writing objects: 100% (1/1), 182 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To https://github.com/ESIPFed/sweet.git
 * [new tag]         v3.6.0 -> v3.6.0

Create the release

Now navigate to the tags area and click on the right hand side edit release notes for the version you are trying to release. From here, paste in a message which directs users to the issues related to the closed milestone for the release you are trying to make. An example can be seen at the SWEET v3.5.0 release notes.

Once you have augmented the release notes, you can progress to make the official release from the same interface as the release notes e.g. click 'Release'.

Update all owl:versionInfo statements

After release, the Turtle files in the sweet/src branch are now a working version of the next release. The process of updating all of these can be done automatically with the following commands at a prompt (choose one):

MacOS/zsh

$ find . -name '*.ttl' -print0 | xargs -0 sed -i "" "s/owl:versionInfo \"3.5.0\"/owl:versionInfo \"3.6.0\"/g"

bash/ksh

$ find . -name '*.ttl' -print0 | xargs -0 sed -i "s/owl:versionInfo \"3.5.0\"/owl:versionInfo \"3.6.0\"/g"

Basically, the above command prints out all Turtle files and then merely makes an in place string substitution to update the version number. Make sure you change the 3.5.0 and 3.6.0 to whatever the release version is you are trying to make.

Once you have done this, commit the changes to master branch and push the changes to the remote origin master branch.

Forge a release announcement

Please make a new entry at the Community Announcements wiki page an example can be seen here.

Make an Announcement

As release manager it is absolutely down to you to ensure that as many people as possible know about the release. This involves, but is not limited to

Any problems?

Contact Lewis John McGibbney at lewis dot j dot mcgibbney at jpl dot nasa dot gov

Clone this wiki locally