Skip to content

SWEET Release HOWTO

Jump to bottom
Lewis John McGibbney edited this page Jan 16, 2018 · 11 revisions

Purpose and intended audience

This document is purposed for SWEET release managers. It was originally compiled by Lewis John McGibbney so issues should be reported to him. 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.0.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

Next, make sure that the owl:versionInfo entry within each file appropriately matches the release version you are trying to make. The process of updating all of these can be done automatically with the following command

$ cd sweet
$ find . -name '*.ttl' -print0 | xargs -0 sed -i "" "s/owl:versionInfo \"3\"/owl:versionInfo \"3.0.0\"/g"

Basically, the above command prints out all Turtle files and then merely makes a string substitution to update the version number. Make sure you change the 3 and 3.0.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.

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.0.0 -m "SWEET version 3.0.0"

Then push your tag to remote origin

$ git push origin v3.0.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.0.0 -> v3.0.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 tot eh closed milestone for the release you are trying to make. An example can be seen at the SWEET v3.0.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. Release.

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