Library versioning #48
Comments
|
I agree, let's get this one done asap! |
|
Looks like I'll have some time for this one. Will get to this before merging the PR:s |
Pallinder
added a commit
that referenced
this issue
Oct 30, 2018
Background To make sure people can better rely on us and to prepare for the new golang package management system we need to start to be more serious about versioning. It was therefore decided to start relying on [Semver](https://www.semver.org). This PR introduces an update to the README containing information about how we deal with releases and also introduces a CHANGELOG.md that can be used to keep track of versions. It was decided to start on V1.0 since this is used in production. Discussions can be found in issue #48 Changes - Update README.md to include link to CHANGELOG.md - Update README.md to include information about semver - Add CHANGELOG.md for changelog related info
|
Merged in 422dd1e |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It's kinda odd to see a cool library still not being versioned even though it seems to have been around for 5 years already and going through a decent evolution.
Please consider:
CHANGELOG.mdfileThis would greatly improve the library user experience and the seriousness of the project by allowing the user to achieve reproducible builds when using dep for example.
Currently, there seems to be no guarantee on backward-compatibility so the current release would need to start with
0.1according to semver, though if it's already production ready then start with1.0right away.This issue is loosely related to #47
The text was updated successfully, but these errors were encountered: