README.md: Should we switch to latest.release style rolling versions

[cachescrubber]

Documenting the current Maven and Gradle plugin versions has been a source of great confusion over the last weeks. Should we switch to a latest, or latest.release style rolling version or is it important to stick to a known release?

If we decide to use a rolling version, how to do it properly?

• Maven: Stackoverflow
• Gradle supports latest.release

[kthoms]

I consider LATEST for plugins as an anti-pattern. For builds it is important that they are reproducible. This means especially that the plugin versions are fixed.
I would rather solve this on CI level and establish a build that frequently just updates the respective files with the latest version with which the build was actually built & tested with.
I could work on that.

[cachescrubber]

For a normal build I absolutely second your comment above. This request targets especially to this projects README, not the pom itself. Migrating a project from camunda to operaton would usually be a one-shot task, not a reproducible build step. For example, see the OpenRewrite documentation on running a maven task without modifying the build.

I just experimented a bit:

No plugin version, explicit recipe version

mvn -U org.openrewrite.maven:rewrite-maven-plugin:run \
 -Drewrite.recipeArtifactCoordinates=org.operaton:migrate-camunda-recipe:1.0.0-beta-2 \
 -Drewrite.activeRecipes=org.operaton.rewrite.spring.MigrateSpringBootApplication

No plugin version, rolling recipe version (RELEASE). IMO this variant is used throughout the openrewrite recipe docs.

mvn -U org.openrewrite.maven:rewrite-maven-plugin:run \
 -Drewrite.recipeArtifactCoordinates=org.operaton:migrate-camunda-recipe:RELEASE \
 -Drewrite.activeRecipes=org.operaton.rewrite.spring.MigrateSpringBootApplication

I still need to find a good gradle based example project in order to test the plugin execution with gradle.

[kthoms]

This only works if you explicitly update the plugin with mvn -U. Further this makes it harder for issue reporters if they do not know the used version. Updating the README is something I can automate for you.

[cachescrubber]

Conclusion

Let's go with fixed versions in our documentation. The README basically tracks three versions in order to provide simple usage / getting started instructions. These are internal and external.

Internal Versions

• The Recipe Version - latest release

External Versions

• OpenRewrite Maven Plugin - latest compatible release
• OpenRewrite Gradle Plugin latest compatible release

Note for Maintainers

• Avoid inconsitencies. These versions occur multiple times in the documentation. Keep this in mind when accepting issues or pull requests regarding version bumps.
• The plugin versions are not covered by dependabot, so a regular manual check is necessary.
• We need to assure compatibility with the documented plugin versions.

@javahippie @kthoms lets see how we can make this fool proof and automate what is possible. As first step - what would be a good place to document the maintainer notes?

[cachescrubber]

related: #153