versioning scheme and changelogs

[vrothberg]

This is a kind request to change the versioning scheme from the current incremental-integer scheme to something more expressive, e.g., to semantic versioning (https://semver.org/).

For packaging varlink, it would be really nice to provide a changelog for each release. I've recently added a simple make target to Podman to facilitate this task (see https://github.com/projectatomic/libpod/blob/master/Makefile#L168).

[larskarlitski]

I don't think semantic versioning is beneficial to this project. We don't plan on breaking API and having no major version number means that we'll never be tempted to.

[vrothberg]

@larskarlitski, thanks for the quick reply.

I don't think semantic versioning is beneficial to this project. We don't plan on breaking API and having no major version number means that we'll never be tempted to.

I guess that adding features, and fixing or even deprecating existing ones is an integral part of developing an API, so it might come in handy in case the API changed.

Semantic versioning is very explicit about such things, and makes things easier to parse and understand, especially from a release and maintenance point of view, but I am wearing my distribution hat at the moment ;-)

[larskarlitski]

I guess that adding features, and fixing or even deprecating existing ones is an integral part of developing an API, so it might come in handy in case the API changed.

That's was my point: the API might change, but we only ever add things, never remove or change semantics. Breaking changes are a nuisance for consumers of an API. A single version number is enough for that. (Note that there's always symbol versioning in the rare case that we do want to reuse a symbol for a different need.)

I understand that this is a bit unusual, but we feel strongly about it. Sorry about that :)

[vrothberg]

I understand that this is a bit unusual, but we feel strongly about it. Sorry about that :)

I am all good with it :) Thanks for taking the time to explain.

[kaysievers]

In short: we just omit the "major" number, because we intend to never use it. In-library symbol versioning will do that for us, just like the glibc model, which will unlikely ever have a major version bump ever. We use the "minor number" as our release number. The "patch" number can be used by distributions.