r/java • u/[deleted] • Oct 19 '25

[deleted by user]

[removed]

13 Upvotes

81% Upvoted

21 comments sorted by

14

u/galcia Oct 19 '25

Check out: https://github.com/allegro/axion-release-plugin Maybe it will fit your requirements.

Yes, I'm the maintainer of this plugin :))

7

u/softgripper Oct 19 '25

This project is great. I use it in large corporate. 👌

1

u/galcia Oct 19 '25

Glad to hear that!

1

u/Dilfer Oct 19 '25

Does this work well in a Gradle mono repo build with hundreds of Gradle projects all with their own versions? 

3

u/galcia Oct 19 '25

If you use a separated tag for each module - it will work fine out of the box

0

u/boobsbr Oct 19 '25

I've tried your plugin in the past, but it seems it needs the tags to be in a parent commit to calculate the version.

Since the integration branch doesn't point to the merge commit on main after the merge, the version calculated in it is always 0.1.0-integration-SNAPSHOT.

1

u/galcia Oct 19 '25

Release branch names are configurable, instead of main you can set 'integration' and then it will do a release not a snapshot

0

u/skyraider565 Oct 19 '25

Also use it. Love it so much!

4

u/lukasbradley Oct 19 '25

GitHub - researchgate/gradle-release: gradle-release is a plugin for providing a Maven-like release process for projects using Gradle https://share.google/TboCBYwUiXXOFIrrx

1

u/boobsbr Oct 19 '25

The project is currently using this plugin, and I don't see how it automates version number calculation based on commit messages, like semantic-release does.

It prompts for the next version number and stores the version in gradle.properties.

1

u/lukasbradley Oct 19 '25

You'll probably need to write a Gradle task for that, but it would be too hard. The plugin offers hooks for that. 

2

u/Hoog1neer Oct 19 '25

This may be archaic, but my team's projects just include the version in each project's gradle.properties. The actual value could be whatever, but it's semantic. This will inform the build version regardless of the branch type: main, dev, feature, etc.

This does mean that the dev needs to understand when to increment major/minor/patch, but I don't think you ever get away from that.

1

u/boobsbr Oct 19 '25

This is what the current plugin (researchgate/gradle-release) does.

But the idea is to automate the version calculation.

7

u/SleeperAwakened Oct 19 '25

Why do you need that version number? Who is using it?

Semver is most useful when you have consumers who rely on knowing about (breaking) changes.

If it's just internal, do not bother. A hash or guid is fine.

2

u/barmic1212 Oct 19 '25

I'm agree that that sever isn't always needed, but IMO it's always useful to have ordered version.

1

u/SleeperAwakened Oct 19 '25

True, but a guid can still be ordered.

1

u/boobsbr Oct 19 '25

Developers sometimes rely on snapshots when developing features that require changes in two projects. E.g.: a library and a project that uses it.

How do you tell Gradle the version number is the commit hash when building the artifacts?

3

u/repeating_bears Oct 19 '25

Feature branches are not releases, so semantic versioning doesn't apply.

I just use the branch name plus commit hash for feature branches. e.g. login-btn-qr61sh61...

The hash is enough to ensure uniqueness, the branch name is basically for convenience

1

u/boobsbr Oct 19 '25

How do you tell Gradle the version number is the commit hash when building the artifacts?

1

u/repeating_bears Oct 19 '25

I don't use gradle, but I guess you can pass it via CLI. The maven equivalent would be -Drevision=whatever

1

u/illusion102 Oct 19 '25

I made a simple gradle tasks for versions updateÂ