Document compatible rewrite-maven-plugin and rewrite-gradle-plugin on release for quarkus-updates

[gsmet]

As part of the quarkus-updates project, we have been struggling a bit to find a setup that would actually reflect the current version used by the Maven plugin and the Gradle plugin.

Typically, when developing our recipes and tests, we want to make sure that we are using the version of the rewrite-bom that is used in the Maven plugin - and ideally it would be the same one used in the Gradle plugin or we will have some discrepancies.

And similarly, for the Gradle plugin.

A good example of this issue is that a new version of the Maven plugin was released yesterday, apparently together with the core project but the Maven plugin is still referencing 8.11.3, while the core project (with I think the fix I wanted) is at 8.11.5.

I can enforce 8.11.5 in my project but when running the Maven plugin, the jars around will be at 8.11.3 thus not having the fix.

I was wondering if there was a good strategy to actually make sure that we are using consistent versioning, apart from manually checking each update?

Also was it a mistake that 5.17.0 of the Maven plugin is pointing to 8.11.3 and not 8.11.5?

[timtebeek]

Hi @gsmet ; Ideally these issues are rare because of some automations we use, and I'm not quite sure how this one slipped in. I've flushed it out with a new release though, and followed up with a release of rewrite-quarkus for good measure.

To give you a bit of background: all our repositories can have individual patch releases, and depend on each other's latest version. For the Maven plugin we have a small step ahead of a release to ensure we pick up any new versions before a release:
https://github.com/openrewrite/rewrite-maven-plugin/blob/609deb5040bfcfb6f3c60bddf4f7d50009e284b5/.github/workflows/publish.yml#L30-L33

When I just ran the release for rewrite-maven-plugin it did indeed pick up the version of <rewrite.version>8.11.5</rewrite.version> that was released just before: openrewrite/rewrite-maven-plugin@91600ee

We (I ;)) take extra care to only release the next modules and plugins downstream once the previous ones are fully available from Maven Central. That's also why I'm puzzled how we ended up not aligning as well with the last plugin release.

Separate of any individual patch releases, we do a full release train once every two weeks or so, which sees updates to all modules and plugins, and culminates in a release of our rewrite-recipe-bom (note that's separate from rewrite-bom). That helps align the version numbers for the majority of our users, but the Maven or Gradle plugins aren't in there, as those versions can't be managed with a BOM as far as I know. We could add the plugins to the BOM if that would help your case, with the note that it is a bit odd to have them there of course.

Open to other options or suggestions, and happy to help work through any issues that might remain.

[gsmet]

OK, I understand things better now.

Yeah, you cannot define the versions of plugins in a BOM.

I would not add the Maven and Gradle plugins as a dependency in the rewrite-recipe-bom but I think it would be nice to have their versions in a comment if it's doable so that we could align everything from a quick look at rewrite-recipe-bom.

I'm not sure how you build this BOM though and if it would be easy to do it.

Another thing that would be extremely helpful is if you were able to inject the versions of the plugins in the GitHub releases notes of the rewrite-recipe-bom releases. When Dependabot creates a PR (typically here: https://github.com/quarkusio/quar), the release notes are accessible so just having a look at them would give us the information and we would align the plugins right away.
Obviously, if it's just us having this problem, it's probably not worth it but I think it could maybe help others too.

I'm not exactly sure how pluggable your release process is but https://github.com/hub4j/github-api/ might come handy, we use it a lot for our automation.

[timtebeek]

Thanks for the suggestions! I like the option of adding the version numbers to the release notes; I'll see if I can fit that in. For now I've added the compatible plugin versions to the release notes of the new rewrite-recipe-bom; hope that already helps:
https://github.com/openrewrite/rewrite-recipe-bom/releases/tag/v2.5.4

[gsmet]

Yeah, I can confirm it's really useful: quarkusio/quarkus-updates#99

[timtebeek]

I've renamed and moved this issue to reflect the changed scope; we're revising our release process and will plead for this to make it in.

[crankydillo]

I'm pretty sure the ask here reflects what just happened to use. This patch release brought in this patch-released change, which is breaking for us (for various reasons we needed to use Java constructor for instantiation).

Our build uses the recipe-bom, which is currently coupled with a rewrite-maven version that does not have this change. So our build succeeds even when keeping up to date. So far, we have been guiding our users to stay current with rewrite-maven-plugin patch releases, but that broke us because some of our recipes just stopped getting included. What makes things worse is they are more or less silently excluded (code).

So +1 on seeing a compatibility matrix. Additionally, is there any thought to delaying the Maven plugin release until after this BOM is released?

[timtebeek]

Ah sorry to hear! The compatibility matrix is pretty much every release of rewrite-recipe-bom that's listed here:
https://github.com/openrewrite/rewrite-recipe-bom/releases
Those are the versions that were released together, and recommended to be run together.

We roll up all the changes over the past two weeks into new releases on a schedule; the next one is slated for tomorrow to flush out any of these issues.

You're right in pointing out that .patch releases of the Maven plugin might pick up a newer OpenRewrite release that does not play well with older recipe modules. For those cases where you want to be on the latest we also have our snapshot versions, to carry you over until the next release.

We of course never intend to break things, and to stay predictable; that's why every two weeks you get new .minor versions of OpenRewrite and the plugins, and any modules that were changed. The problems you're seeing here are unique to .patch versions of the plugins, so you can ignore those if needed.

On our end we do need .patch versions of the plugins to be able to bring changes to our users through Moderne, which is why you're seeing these releases at all. They'd only fall within the two week window until the next release though.

[crankydillo]

Ah, I missed that rewrite-maven-plugin is somehow managed in this bom, unless I'm misreading your release notes. I think this project uses gradle-magic I'm unaware of:)

[timtebeek]

Ah, I missed that rewrite-maven-plugin is somehow managed in this bom, unless I'm misreading your release notes. I think this project uses gradle-magic I'm unaware of:)

It's not as much managed (no such mechanism that I'm aware of) as it is released together and announced in tandem, such that there's always a combination that will work well. We of course recommend the latest based on what's listed here, but welcome to pick any other aligned versions from there.

[timtebeek]

We've now automated the release process to document these compatible versions automatically:
https://github.com/openrewrite/rewrite-recipe-bom/releases/tag/v2.23.2

Thanks for the nudges!