versioning scheme and changelogs about libvarlink HOT 5 CLOSED

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.

from libvarlink.

@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 ;-)

from libvarlink.

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 :)

from libvarlink.

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.

from libvarlink.

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.

from libvarlink.