Tagged Releases

[opalmer]

So after using go-gerrit for a while I've been starting to think we should be tagging releases. There's a few reasons for this:

• Vendoring can take advantage of this and lock down to specific versions of go-gerrit. You can technically do this with revisions too but tags are easier to work with and more obvious.
• There's no a good way to handle breaking changes at the moment. For example, GetReflog can take from and to url parameters but the current implementation of go-gerrit does not support this. The change could be made in master now but it would be a breaking change and it does not feel appropriate to make a new function.
• There have been several contributions for everything from new features to major bug fixes. It would be nice, though not a requirement, to keep a small changelog of these kinds of changes so when you upgrade from 0.1.0 to 0.1.1 you have a better understanding of changes between versions.

[opalmer]

@andygrunwald, thoughts?

[andygrunwald]

Good idea. Go for it! The only important note from my side: Release notes. These release notes should add value and answer questions like "What is new? What bugs were fixed? Why should i upgrade? Any breaking changes for the upgrade and do i have to adjust my code?"

Personally i like the release notes from etcd, see https://github.com/coreos/etcd/releases They are useful, clear and well structured.

@opalmer Afaik you own the rights to do releases and tags. If not ping me and i will grant those to you. Othwerwise: Good idea :)

Will you handle this ticket and close once a release is done?

[opalmer]

Done! It's pretty close to what etcd does though not exactly (we don't have a NEWS file yet). For my own project, I made it a policy to update the changelog for every new PR, we probably could do the same here.

[andygrunwald]

Awesome work. Thank you. Regarding the changelog: Yes, why not :)