Versioning

Libmypaint uses Semantic Versioning 2.0.0, with zero or more prereleases between subsequent releases. The development cycle between releases looks like:

Version	Release Tarball	Pkg-config version¹	Release Tag	Purpose
A.B.C-alpha.0	—	A.B.C	—	First commit after a stable release.
A.B.C-alpha.0.N	—	A.B.C	—	Build from git between releases.
A.B.C-beta.0	libmypaint-A.B.C-beta.0.tar.xz	A.B.C	vA.B.C-beta.0	First beta release.
A.B.C-beta.0.N	—	A.B.C	—	Build from git between releases.
A.B.C-beta.1	libmypaint-A.B.C-beta.1.tar.xz	A.B.C	vA.B.C-beta.1	Second beta release.
A.B.C-beta.1.N	—	A.B.C	—	Build from git between releases.
...	...	A.B.C	...	...
A.B.C	libmypaint-A.B.C.tar.xz	A.B.C	vA.B.C	Stable release.

¹ Due to limitations of pkg-config, pre-release versions have the release's final version in the Version field of libmypaint.pc.

Active development

The "alpha" denotes the active development cycle. We do not make tarball releases in this phase. New features will be merged. You will be able to build it and install it provided that you do so from git.

Beta testing

During the beta development cycle, new features will be put on hold and translated strings will be frozen. We may make prerelease tags and tarballs available on github during this phase.

Stable release

Generates the tarball everyone expects. Procedure for maintainers:

1. Ensure that the draft release is created and fully described.
2. Edit configure.ac and edit the version fields. Ensure that the prerelease version field is blank.
3. make distcheck
4. make dist
5. Sign the resultant tarball.
6. Upload the tarball to the release page.
7. Commit changes locally, tag the commit as vA.B.C, and push both the tag and the commit to github.
8. Publish the release.
9. Edit configure.ac and increment the version fields. Ensure that the prerelease version field now reads exactly alpha.0. There is no tag for this.
10. Commit the result, and push it immediately to start the next development cycle.