Release Process

This outlines the current process for how issues get assigned and eventually make it into a release.

This method is not set in stone, it will change as needed.

Milestones

There is at least 4 active milestones at any given time:

1. The current version milestone. For example, "0.9.x".
2. The next version milestone. For example, "0.10.x".
3. Future Release - This milestone is a placeholder for all issues that are planned to go into a future release, but it is not yet clear what that release will be.
4. Will Not Release - This is a placeholder milestone for items that will not be released in any future version. This includes questions, undecided or changes to big we cannot decide if they should even be released.

Incoming Issues and Pull Requests

All new issues and pull requests will be assigned an active milestone.

• Usually simple bugs and small issues will be assigned to the current version milestone so that they will be released in a patch release (like 0.9.2).
• New features or larger changes may be assigned to the next release milestone.
• Most issues will fall into the Future Release milestone.

The milestone on issues change as decisions as discussions are decides or new versions are being prepared.

Performing a Patch Release

We aim to have rapid and small releases during this early stage. A patch release incremented the last number in the semver. For example, v0.9.2 -> v0.9.3. A patch release almost always does not introduce large features or breaking changes. It is usually reserved for small bug fixes and very small issues.

Once one or more pull requests will go in it is time to release those changes as a patch on the current version:

1. On the master branch, commit the new version in main.go. Normally we would never commit to master but this is a change that should never break the build. Tip: You can edit the file directly here.
2. Tag the new HEAD with the version (all tags have a v prefix). Push the new tag to Github.
3. One the tag is pushed it will show as an unpublished versions on the Github releases page. You will now need to edit it, the release name will be the same as the tag. The description should contain bullet points of each of the pull requests and issues resolves in this patch. Here is an example.

Performing a Minor Release

A minor release increments the centre number in the semver. For example, v0.9.2 -> v0.10.0. It usually indicates that there are new features, large refactoring or small breaking changes against the previous minor release.

The process works the same as a patch release. The only difference is there is a few steps before hand.

1. There should hopefully be no issues left in the current version milestone. If there are still issues they need to be reassigned to the next version.
2. The current version milestone will now be 100% complete and can now be closed.
3. Create a new milestone for the next minor release.
4. Perform the same steps as Performing a Patch Release.
5. There may be some documentation that needs updating, such as the Project Progress.