Define strategy of versioning

[jraska]

• How to automatically update version?
• How to bump major/minor etc.
• One option is using the tag

[lordcodes]

I have a set of Gradle tasks: prepareRelease[Major|Minor|Patch]. They increment the appropriate part of the version stored in a Kotlin file in buildSrc. They also need to set lower parts of version to 0.

Increment minor from 0.1.2 goes to 0.2.0 for example.

To perform a release, I then have a Gradle task which uses the version in that file to create a Git tag. CI has a workflow that is triggered by Git tag and does a release to Google Play internal channel.

The release workflow uses Gradle tasks inside the project to do each part, so that if I really needed to (issues with CI) I would do all the release locally (provided I put the secrets where they needed to be).

My release workflow also does other things that are needed such as creating Jira release, adding that to all the tickets contained in the release, marking it as released, then posting all the Jira task names and IDs as release notes message to a Slack channel.

I found it very interesting putting it all together! Will happily show you what I have sometime, if you are interested.

[jraska]

Yes I'm definitely interested! Thanks a lot for the notes :)

I tried to think about the requirements I have:

1. Complete release to Google Play and all other things like Jira should happen by executing single task - publishRelease
2. It should be executable both from local environment and CI, also needs to be able to trigger manually on CI
3. It should be clear in git which version a commit points to.
4. Possibly 100% of all logic in Gradle
5. The only manual action should be promoting to Beta and staged rollout. - These could be automated as well.
6. As trivial strategy as possible.

One thing related to 3. is if the CI needs to modify anything in VCS or not? Because I was thinking about variants on how to avoid this.

The thing is where this version number should be - one options is the version number in file as you mention, other one we used in the past is having the latest git tag as this reference and push the next tag based on this. We can discuss that as well :)

[jraska]

Will try this with GitHub actions :)

[lordcodes]

This is exactly what I do right now for GetBusy.

…

On Thu, 18 Mar 2021 at 22:56, Josef Raska ***@***.***> wrote: [image: Automatic release] <https://user-images.githubusercontent.com/6277721/111708033-66939100-8845-11eb-8643-439ff47d05ba.png> Will try this with GitHub actions :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#236 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACWLLEYKU5SINEMLTQPFNHTTEKAI3ANCNFSM4NA7BDHQ> .

[jraska]

@lordcodes do you use Milestones or can't we somehow provide backward reference into each PR to release directly? The Milestone feels like a patch of this not being possible :)

[lordcodes]

We use Jira so all done on there for now.

…

On Thu, 18 Mar 2021 at 23:15, Josef Raska ***@***.***> wrote: @lordcodes <https://github.com/lordcodes> do you use Milestones or can't we somehow provide backward reference into each PR to release directly? The Milestone feels like a patch of this not being possible :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#236 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACWLLE3BOFDACP6GTGGHFOLTEKCPTANCNFSM4NA7BDHQ> .

[jraska]

Ah ok :) thanks

[jraska]

Resolved by #445

Example release: https://github.com/jraska/github-client/releases/tag/0.24.0

Version is bumped for following release: example automatic commit: 88c0d9a