Skip to content

Commit

Permalink
Bump API version more & add VERSIONING.md.
Browse files Browse the repository at this point in the history
Recent changes on master have changed the public API in a backwards-
incompatible way. The next release will therefore be 2.0.0, not 1.4.0.

Add a VERSIONING.md for reference.

Closes mypaint#92.
  • Loading branch information
achadwick authored and briend committed Jan 25, 2019
1 parent 66e0e3b commit f3441d2
Show file tree
Hide file tree
Showing 2 changed files with 45 additions and 2 deletions.
43 changes: 43 additions & 0 deletions VERSIONING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,43 @@
# API and ABI versioning policy

libMyPaint cannot afford to be sloppy about its version numbers because
other projects depend on it.

API versions on `master` increment ahead of the upcoming release
as and when features and changes are added. ABI versions are always
updated immediately before each release, and _only_ then.

1. The `master` branch contains the _future release_'s API version
number. This version number is updated as and when new features and
API changes are committed to the master branch. Do this by updating
[configure.ac][]'s `libmypaint_api_*` macros as part of your commit.
The reference point for these updates is the current stable release's
version number.

* Rules for the API version number: libmypaint uses
[Semantic Versioning][].

* Note that the major and minor components of the API version number
form part of the _soname_ for binary library files used at runtime,
but they're not part of the `libmypaint.so` symlink used by your
compiler when it tries to find a dynamic library to link against.

2. We use prerelease suffixes at the end of the API version number
during active development to help you identify what you are building
against. The API version number of a formal release normally does not
contain any prerelease sufffix.

3. For ABI versioning, libmypaint does exactly what the GNU docs say. We
will always update some part of the ABI version number immediately
before each public release. This is done by tweaking
[configure.ac][]'s `libmypaint_abi_*` macros. ABI versions are _only_
bumped immediately before a release, and maintain their own (somewhat
weird) version sequence that's independent of the API version number.

* Rules for the ABI version number: refer to
[Updating library version information][]
in the GNU libtool manual.

[configure.ac]: ./configure.ac
[Semantic Versioning]: http://semver.org/
[Updating library version information]: https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
4 changes: 2 additions & 2 deletions configure.ac
Original file line number Diff line number Diff line change
Expand Up @@ -2,8 +2,8 @@
AC_PREREQ(2.62)

# API version: see https://github.com/mypaint/libmypaint/wiki/Versioning
m4_define([libmypaint_api_major], [1])
m4_define([libmypaint_api_minor], [4])
m4_define([libmypaint_api_major], [2])
m4_define([libmypaint_api_minor], [0])
m4_define([libmypaint_api_micro], [0])
m4_define([libmypaint_api_prerelease], [alpha]) # may be blank
# The platform version is "major.minor" only.
Expand Down

0 comments on commit f3441d2

Please sign in to comment.