-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
versioning scheme and changelogs #8
Comments
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. |
@larskarlitski, thanks for the quick reply.
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 ;-) |
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 :) |
I am all good with it :) Thanks for taking the time to explain. |
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. |
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).
The text was updated successfully, but these errors were encountered: