Automate release process

[yurishkuro]

Current release process is documented in the readme and is fairly painful. The most ideal process would be to push a tag and have the release happen automatically (but I am not clear what happens to the changelog in this case). Using a make command would also be acceptable if it can do a bunch of changes in a row like bump the version, publish, bump version to snapshot again, and then automatically close & release the repo from staging to maven via sonatype.

[vprithvi]

It looks like the nexus steps can be automated using https://github.com/Codearte/gradle-nexus-staging-plugin while the release steps can be automated using https://github.com/researchgate/gradle-release

We would need to get another username/password for the travis user to be able to publish to nexus

[pavolloffay]

The tag is really missing here. W could also use something similar what OT uses.

(but I am not clear what happens to the changelog in this case)

I guess this can be modified manually before pushing release tag.

[yurishkuro]

@pavolloffay how do you guys do releases of Java components in hawkular?

[pavolloffay]

Directly to jboss nexus. It's also rather a manual approach.

[pavolloffay]

There are some plugins which could be used https://github.com/researchgate/gradle-release

[mabn]

There's also https://github.com/ajoberstar/gradle-git/wiki/Release%20Plugins
Other options are listed at the bottom of this page.

[jpkrohling]

Directly to jboss nexus. It's also rather a manual approach.

That's false. We have Jenkins jobs that does most of the tasks for us, including the creation of GitHub releases (with the compiled artifacts).

Note the "Perform Maven Release" on the left-hand side:

[jpkrohling]

Currently blocked by: https://issues.sonatype.org/browse/OSSRH-32483
Temporary branch: https://github.com/jpkrohling/jaeger-client-java/tree/JPK-AutomateReleaseProcess

[yurishkuro]

@jpkrohling google doesn't find OSSRH-32483, do you have a link?

[jpkrohling]

I just submitted #201 , which implements the "push a tag" approach. In fact, most of the work had been done already, I just needed to set the version to set the version to be the tag and add the appropriate Gradle properties.

What I have also planned is to add the closing/releasing of the Nexus repository, but I'd do that after a couple of releases to mature the process implemented by the linked PR, to make sure we don't release a broken repository.

What I have not done, and I'm not sure we should do it there, is to bump the version. The main problem is that the automatic release procedure can't tell if the release is a micro, minor or major change. So, we'd still require version changes to happen manually on master.

[pavolloffay]

For bumping the version we could do this.

Regarding auto-version bump we could always bump the patch version. The pattern is following:

major version bump:

• we are on 0.1.0-SNAP and push is 1.0.0 it releases 1.0.0 and bumps to 1.0.1-SNAP
• we are on 1.9.0-SNAP and push is 2.0.0 it relsease 2.0.0 and bumps to 2.0.1-SNAP.

minor version bump:

• we are on 0.0.3-SNAP and push is 0.1.0 it releases 0.1.0 and bumps 0.1.1-SNAP

it basically always releases the tag you pushed and bumps patch-snapshot based on that version.

[objectiser]

What about:

• if release version ends with .0 then add 1 to the minor version with -SNAPSHOT
• in all other cases add 1 to the release version's patch value with -SNAPSHOT

[jpkrohling]

Note that the version used for the actual release comes from the tag (TRAVIS_TAG). Bumping the version is required to keep the snapshot versions sane, and to serve as a reference to the "next" version.

In the end, the person creating the tag is setting the version.

[pavolloffay]

The current release process requires interacting with sonatype UI which is annoying and people can forget to do it.

@jpkrohling do you know how we could solve it? I think we have something similar in hawkular org. When I was releasing datamining I remember using -Prelease-guiless. It's defined here https://github.com/hawkular/hawkular-parent-pom/blob/master/pom.xml#L1020

[jpkrohling]

Right, it's possible to automate the closing/releasing of the staging repository. I think we kept it manual for now in order to be able to check the staging repo before actually releasing, but I think we can now automate it.

[pavolloffay]

I am +1 for automating it as much as possible. We have also talked about it on gitter channel.

[pavolloffay]

The current release process does not create any commits. By looking at git logs It's hard to see when release happened.

Release readme is not accurate it says that staging repository should be closed manually.

[objectiser]

For maven releases, the commits are usually created due to automatic update of the version. However for gradle I think we need to update the development version manually? If this could be automated in some way it would have the same result.

[pavolloffay]

There are gradle plugins which do the same as maven does.

[pavolloffay]

@yurishkuro @vprithvi do you agree on adding release commits when performing the release? The commits would be automatically added by gradle plugin e.g. https://github.com/researchgate/gradle-release

[vprithvi]

@pavolloffay I agree, but I would prefer much more automation, including automatically bumping the patch version number, updating the change log, etc. It seems that a plugin like https://github.com/mockito/shipkit could work well.

[yurishkuro]

I like the release commits, they make it clear in the history when release happens. It's what we do in other repos too.

[jpkrohling]

Current state: the release process is still problematic. Right now, we end up doing the upload process manually, due to a bug somewhere between the Gradle plugin, Travis and Nexus.

[jpkrohling]

I'm removing myself as the assignee, as I think @pavolloffay has worked on this lately.

[pavolloffay]

There have been some changes to the release bits we are using. Now the fully automated release from travis works well, it closes staging repositories automatically.

To do the release we just have to push a tag. The release version is taken from the tag so no need to update it manually, however after the release it stays with the same value as before the release. We could change it to something version agnostic eg. 999-SNAPSHOT and keep it that way always (https://github.com/quarkusio/quarkus uses the same approach).

This way we still have snapshots - however always 999-SNAPSHOT and we don't have to update the version before and after the release.