Setup automatic versioning, automatically update Readme.md

[mateuszkwiecinski]

Here's my proposal of how the release process could be partially automated. My proposal for the new flow is:

1. Create Github release, pick version in format x.y.z(or x.yy.zzz)
2. Wait until the release gets published on Gradle Plugin Portal
3. Review and merge Automated PR with update Readme version references (example: https://github.com/mateuszkwiecinski/kotlinter-gradle/pull/11) a. if needed, the branch can be modified manually (i.e. to add a new "compatibility" section)
4. Done ✅

The core mechanism for setting proper version is the Axion Release Plugin, which will extract the version from git tags (which is the reason why I have to fetch the repo with tags on checkout) The plugin registers task./gradlew currentVersion (or simply ./gradlew cV) which allows to view the current version

This plugin also makes subsequent build to have SNAPSHOT version set (if this PR gets merged, HEAD of master will return:

) which is a step towards publishing snapshots 😄

As an alternative, I could propose doing something similar to what Jake Wharton's diffuse does - to basically push the tag, and the corresponding workflow will create the release automatically.

I decided to go with the "automated-PR-after-manual-release" approach as it resembles existing approach the most :)

[mateuszkwiecinski]

I should probably think about it more, but I've always been allergic to CI creating PRs -- seems backwards to me.

I can configure the CI to commit to the main branch directly if you prefer, but that's something I've been allergic to 😛

The current release process isn't terrible since github releases are quick to create.

The part I didn't like was to remember when to create the Readme update PR 😛 I wasn't sure if I should do that before triggering a release? Or should I do that directly after? Which versions should I bump? I had to go through past bumps and find the preferred way. Triggering a release from Github UI has its own downsides (Github sends a release notification before the plugin is actually available on maven repository). But yeah, I agree the current release process is convenient enough 👍 If this PR gets merged the only thing I'd like to change would be publishing snapshots, so the plugin builds can be tested easily by others.

Please do think about the proposed changes and let me know if you find any other approach more suitable for this project :) As my final words I can only add this patch can be easily reverted, and we can always go back doing releases manually.

[jeremymailen]

Closing for now as the current release steps are simple enough.