Public Release Procedure for Projects: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 49: Line 49:
Release title: 2.4
Release title: 2.4


Describe the release: Introduced features, bug fixes. This will be part of the release history.
Describe the release: Introduced features, bug fixes. This will be part of the release history. Projects maintain notes to be consolidated into the release announcement in <tt>./doc/release-notes.txt</tt>.


Attach binaries by dropping them here or selecting them: ...
Attach binaries by dropping them here or selecting them: ...


Publish release.
Publish release.

Revision as of 19:17, 6 July 2016

Internal

Procedure

Run release Locally

The procedure will increment the version string appropriately, run tests, commit to git, tag and push to GitHub.

The procedure will also create the binary to be used as "release binary" at the next step.

At the end of the procedure, the Git tag used to tag the release will be displayed, so it can be used at the next step.

Example:

release info

release minor
releasing 2.4, is this OK? [y/n] y
[...]
git add ok
[...]
git commit ok
git tag ok, tagged with release-2.4
[...]
git push ok

[...]

A new minor version (2.4) was released, committed to repository and tagged.
If you want to create an official GitHub release, use tag "release-2.4" and the following binary: ./bin/../target/events-2.4.zip

Make a GitHub Release

Go to GitHub project page -> Releases.

The tag should already by there.

Draft a new release

Tag: release-2.4

The logic should recognize it as "Existing tag"

Release title: 2.4

Describe the release: Introduced features, bug fixes. This will be part of the release history. Projects maintain notes to be consolidated into the release announcement in ./doc/release-notes.txt.

Attach binaries by dropping them here or selecting them: ...

Publish release.