1.0 API Freeze

[adrianmo]

1.0 API Freeze

[adrianmo]

Great idea. Let's use semantic versioning (https://semver.org/).

Where should we keep track of the version in the library? In a constant inside the project?

Maybe we could use go generate to fill a version.go file with the version taken from the tag branch. This could be done automatically by the CI job.

Any other ideas?

[icholy]

The new versioned go proposal expects a git tag using semantic versioning with a v prefix.

git tag v1.0.0
git push --tags

[adrianmo]

I need to go. I'll read that proposal and get back to you tomorrow.

[icholy]

No rush.

edit: I don't think we need anything other than the git tag.

[adrianmo]

Sounds good. But instead of using git tag we could create a GitHub release with some release notes (new features, changes, bugfixes...) and that will create automatically a git tag.

I propose the following workflow:

When we want to release a version, we create a PR from a release/vX.Y.Z branch with:

1. Only one change on a file called VERSION that will be on the project root directory and only contain the version to be released (e.g. 1.0.5)
2. The release notes in the PR opening message. The release notes will have a similar format as the following projects:

• https://github.com/rexray/rexray/releases
• https://github.com/src-d/go-git/releases
• https://github.com/kataras/iris/releases

Then, once both of us approve the PR, it will merged into master and we will create a GH release with the merged version and the agreed release notes.

How does it sound?

I think we could release 1.0.0 once we merge #28.

[icholy]

@adrianmo sounds good to me. We just need to make sure the git tag has a v prefix, so v1.0.0.

[adrianmo]

Sure, we will add that when creating the GH release.