Skip to content

Release process and versioning

Jump to bottom
onox edited this page May 11, 2019 · 16 revisions

This wiki page is used by the current or future release manager to learn and know how to do a release. It is not of any interest to other developers or users.

Versioning

We follow FlightGear's versioning scheme. Development versions have a number that ends with "-git", for example, "2018.3-git", and actual releases get a number without it, for example, "2018.3". After having created a new release for 2018.3, the next development version becomes: "2018.4-git".

Note that development versions are temporary and are not released. Their sole purpose is to have a different version number from actual releases, so that the developers know which version they are dealing with (Git development or an actual released version) when receiving bug reports.

Release process

The release process consists of a few steps:

  1. Update NEWS.md

  2. Update and commit the version number of the new release

  3. Release a new version, which includes tagging the version commit and creating a branch based on the version commit (which should be in the master branch).

  4. On Github, add release notes to the tag, create a new issue for gathering release notes for the next version, and notify a FG developer so that they can copy the branch to FGDATA.

Creating the release must be done a couple of days before May 17th, August 17th, November 17th, or January 17th.

GPG signing key (optional)

Git can sign commits and tags with a GPG key. If you have one (if you are unsure then you do NOT have one), use the following command to set your signing key:

git config --local user.signingkey AABBCCDD

Where AABBCCDD is the ID of your actual key.

Note that git commit uses -S (uppercase), while git tag uses -s (lowercase).

Release a new version

We have to tag the latest commit in master and create a new branch. This new branch is used by the core developers of FlightGear and added to FGData. Any critical bug fixes for this release should be added to this new branch, as well as to master.

For the examples below, we assume that the current development version is "2018.3-git", the new released version is "2018.3", and the next development version is "2018.4-git".

This whole process must be done several days before the dates mentioned above. Around this day, the core developers of FlightGear will wake up and try to copy the new release branch to FGData. If you are too late, their behavior is undefined. It is very unlikely to get any notification from them.

  1. Make sure your current branch is master and that <aircraft-version> in c172p-set.xml contains the version number of the current development version, for example: "2018.3-git".

  2. Update NEWS.md and add a bullet list for the new version, 2018.3. Commit with commit message: "Update NEWS.md for 2018.3 release".

  3. Update the version number in c172p-set.xml to the release version number: "2018.3". Commit the change and use the following commit message: "Version 2018.3".

  4. Add a release tag to the last commit (which should be "Version 2018.3"). Add a tag with the version number of the new actual release. If current development version is 2018.3-git, then the release tag will be: version/2018.3.

    If you have a GPG key (if you are unsure, you do not have one), use the following command to create a GPG-signed tag:

    git tag -s version/2018.3
git push --follow-tags

    You can verify the key with git tag -v version/2018.3.

    Otherwise (if you do NOT have a GPG key) use the following command:

    git tag -a version/2018.3
git push --follow-tags

    You can add a message to the tag. Just use the tag itself, so write: "Version 2018.3".

  5. Immediately after adding the release tag, create a branch for the new release. For example, if the release tag was version/2018.3, then use following command to create a new branch:

    git checkout -b release/2018.3
git push -u origin release/2018.3
git checkout master

  6. Update the version number to the next development version, 2018.4-git. Make sure with git branch or git status that the current branch is master. Open c172p-set.xml and set <aircraft-version> to the new development version: "2018.4-git". Commit and push this change with the following commit message: "Version 2018.4-git" (Add -S to git commit to sign the commit with your GPG key if you have one).

  7. Go to the tags page on Github and add release notes to tag version/2018.3:

    **Features:**

(The list of features)

**Fixes:**

(The list of fixes)

People who have contributed to the 2018.3 release:

- @user1
- @user2

See [`release/2018.3`](https://github.com/c172p-team/c172p/tree/release/2018.3) for any additional fixes added to this release.

Note: this aircraft is the default aircraft in FlightGear. Manually downloading it is not necessary.

  8. Create a new issue called "Gather a list of features and bugs we fixed in 2018.4" with the following content:

    We should gather a list of all the new features, major changes, and bugs we fixed. Please create a list (use \* to create bullet points) here.

**Features:**

* TODO

**Fixes:**

* TODO

Do not forget to update `NEWS.md` before creating the release. See https://github.com/c172p-team/c172p-detailed/wiki/Release-process-and-versioning

    Make sure to add a "help wanted" label.

  9. Move any open issues on the 2018.3 features/release milestones to the Future features/release or 2018.4 features/release milestones. Finally close the 2018.3 features/release milestones (they should be 100% complete).

  10. Notify Stuart Buchanan (@stuartbuchanan) on the mailing list that he can merge the new branch to FGDATA.

Clone this wiki locally