Add automatic release support

[carlosalberto]

Fixes #971

We still need to manually update the version field in build.gradle, but once that is done, creating a branch starting with v. triggers a deployment to Bintray/Maven Central.

See https://github.com/open-telemetry/opentelemetry-java/releases/tag/v0.2.4 as an example (I used this one to verify all works great).

In a future we can play with plugins that automatically update the version and create a tag (such as the Maven Release plugin does).

PS - I'd like to stop repeating all the steps in the different tasks if possible (now we have very similar build, java11 and release tasks). But we need somebody who is a Circle wizard or one who digs enough into this. Anyway, something to do in the future.

[pavolloffay]

@carlosalberto could we have RELEASE.md that describes what a user has to do to release the artifacts to maven central? Maybe also explain what happens in behind the scenes. It is also useful to have a command for releasing locally if something goes wrong.

In jaeger java client (gradle based) we have fully automated release from travis to maven central. It's done by pushing a release tag. The artifact version is kept in gradle.properties and the deploy scripts does similar checks like we were doing in OT ecosystem.

https://github.com/jaegertracing/jaeger-client-java/blob/master/RELEASE.md#automatic-release-preferred
https://github.com/jaegertracing/jaeger-client-java/blob/master/gradle.properties
https://github.com/jaegertracing/jaeger-client-java/blob/master/travis/deploy.sh

https://github.com/jaegertracing/jaeger-client-java/blob/master/travis/deploy.sh

[carlosalberto]

@pavolloffay Great idea, lets definitely do that.

A local command is also available at this moment, so I will include the explanation in such document (however, user will have to provide his/her credentials, but I guess that's taken for granted).

I will do a follow-up on the more-automated part after we get this one merged ;)

[carlosalberto]

@pavolloffay Added a small RELEASE.md file with the current workflow. I suggest we iterate on the more automated work in a follow up PR, as previously stated ;)

[carlosalberto]

@open-telemetry/java-approvers Please review/approve this PR.

[pavolloffay]

The release should be also marked on Github and probably with copied the changelog for that version.

[carlosalberto]

The release should be also marked on Github and probably with copied the changelog for that version.

Sure, we can do that when doing the fully automatized version (that is, right after 0.3.0 and definitely before 1.0)

[pavolloffay]

I mean it should be documented to do that, I am not sure if there is gradle tooling that can update the changelog on Github.

[carlosalberto]

Updated. @bogdandrutu Verify and merge.