Skip to content

Conversation

@vorburger
Copy link
Member

@vorburger vorburger commented Jun 6, 2025

To make the #155 review easier, I'm "forking out" a change that I implicitly made there into a tiny separate PR here, which @shukladivyansh raised a question about (here), so that we can discuss and settle that matter here in isolation, first.

So the <version>0.1.0 which the existing x2 POMs on the current main branch (as of cec9ef3) use is simply wrong. This isn't an "opinion" or a "preference", but simply due to how Maven works. The reason is the following, if I may try to explain:

This project has already release a 0.1.0 version. That's awesome - great!! That is now, of course, a stabled fixed version, agreed? (BTW see the #169 issue, but that's kind of separate from what this is about.)

OK, so now I'm (someone is) using the ADK. For example, say with https://github.com/enola-dev/LearningADK/tree/main/quickstart. Or wherever. That uses ADK v0.1.0. Cool. So now you have ~/.m2/repository/com/google/adk/google-adk/0.1.0/google-adk-0.1.0.jar, right? Great.

Then suppose you (someone; me, or anyone else, or even some tool) does a git clone https://github.com/google/adk-java.git && cd adk-java && ./mvnw clean install it. Or perhaps e.g. use https://jitpack.io. And now... things get REALLY confusing! Do you see why?

Because https://github.com/google/adk-java/tree/cec9ef3cf25e58bd7460fb99ceef2dabe0a64932 (the state of the main branch today) is NOT v0.1.0 (anymore) - of course! But the mvn install from the previous step just overwrote ~/.m2/repository/com/google/adk/google-adk/0.1.0/google-adk-0.1.0.jar.

The way about a million Maven projects out there do this is simply be incrementing the version in the POM as soon as (right after) a version is actually released. This is essentially a "de facto standard best practice" with Maven. The Maven Deploy Plugin even does this completely automatically!

That's why the version in a Maven POM on a main branch should always be a SNAPSHOT of some upcoming planned future release. Ergo, since 0.1.0 has already been released, what's now on the main branch is what's (eventually) going to be (thus today a "SNAPSHOT" of) what will later be a 0.1.1. (Or a 0.2.0, or a 1.0.0, or whatever number. What exactly that number is is much less important, and a sort of separate conversation. The real point is simply that it should never ever still be the version of something that was ALREADY released. One might even further bump it later again, e.g. if initially only a maintenance patch release was planned, but then that never was required and only directly a major release came out? Then no worries, no harm done, the 0.1.1-SNAPSHOT can be changed again, on the main branch, to e.g. a 0.2.0-SNAPSHOT, at any suitable later time.)

I hope that this helps to clarify. Please let me know if this explanation is not clear enough, and I'm happy to help.

@glaforge FYI

Copy link
Contributor

@Poggecci Poggecci left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the thorough explanation on this!

@copybara-service copybara-service bot merged commit 631e116 into google:main Jun 10, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants