Use semantic-release for easy releasing

[jcchavezs]

One day @adriancole said:

[...] I'd like to stop being the person who has to do everything

And I think he is right, we could have all this process automated by using semantic-release. In their own words, it solves the problem:

semantic-release automates the whole package release workflow including: determining the next version number, generating the release notes and publishing the package.
This removes the immediate connection between human emotions and version numbers, strictly following the Semantic Versioning specification.

I used it in a few projects at Typeform (how does it work?) and it worked and I believe zipkin-finagle could be a great first project to try this out.

Opinions?

@adriancole @openzipkin/devops-tooling

[codefromthecrypt]

more than open to testing new things, especially if you are willing to put in the effort to setup. Maybe we can try something like this for a future "version-bump, then release" patch thing. later, that commit might be written by automation, too! (here in zipkin-finagle, automating this is a bit less impact as it is a leaf on the dependency tree.. good choice to try here)

[abesto]

First time I hear about semantic-release; it looks like a great idea to me. To be clear, this means that when a maintainer approves a merge, they need to (a) be sure to check that the commit is correctly labeled for the change level (this is new) and (b) that merging triggers a release, there isn't an extra opportunity for a manual safety check – correct? Methinks these are way cheaper than manually releasing, so I'm all for trying it out.

[codefromthecrypt]

Right now is really easy. Only thing this allows is easy release from phone as creating git tag from phone is mildly annoying. Is this the main win?

…

On 18 Feb 2018 4:58 pm, "Zoltán Nagy" ***@***.***> wrote: First time I hear about semantic-release; it looks like a great idea to me. To be clear, this means that when a maintainer approves a merge, they need to (a) be sure to check that the commit is correctly labeled for the change level (this is new) and (b) that merging triggers a release, there isn't an extra opportunity for a manual safety check – correct? Methinks these are way cheaper than manually releasing, so I'm all for trying it out. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/openzipkin/zipkin-finagle/issues/41#issuecomment-366501665>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD61-CMVSxSVctQkAgPA0VFUESRqO4Zks5tV-Y8gaJpZM4SJgs-> .

[abesto]

I don't know about “main”, but the two other considerations for me are:

• semantic-release seems to come with full-fledged release implementations; meaning we could possibly get rid of the long, complex bash scripts wrapping Maven
• a point release on each relevant commit either (1) is overkill and noisy or (2) provides great cadence, allowing users to always get the latest and greatest, while also providing fine-grained control over what version / update level they want. This one's more philosophical, so whether it's a pro or a con, I'll leave to you :)

[codefromthecrypt]

PS I've not really done many releases here until today :) I also think that this repo is a little more complicated than others, so if picking guinea pigs we can try another :D