Croway commented on PR #132: URL: https://github.com/apache/camel-upgrade-recipes/pull/132#issuecomment-6286928479
Agreed, 4.22 is LTS and the aggregate is what #129 tracks. While sizing it I found a blocker for any 4.22 LTS chain, fixed in ebbf961: `camel419.CamelSpringBootMigrationRecipe` bumped every `org.apache.camel` / `org.apache.camel.springboot` coordinate to `@camel-latest-version@` / `@camel-spring-boot-version@` as its first step. Every Spring Boot chain from 4.20 on reaches 4.19, and OpenRewrite's `UpgradeDependencyVersion` never downgrades (`VersionComparator.upgrade` only accepts candidates >= current), so a `CamelSpringBoot422LTSMigrationRecipe` would have left users on 4.23.0 and its own 4.22.2 bump would have been a no-op. The bumps now run first in `CamelSpringBootMigrationRecipe` (`latest.yaml`), the latest path is unchanged, and the version recipes only migrate code, as in the core module. `CamelSpringBoot422Test#versionRecipesDoNotBumpCamelVersions` guards it and `RECIPE-CONVENTIONS.md` documents the rule. The aggregate itself (core `4.22LTS.yaml`, the Spring Boot mirror and a `CamelUpdate422LtsTestSuite`) has to target 4.22.2, so its version tests only pass once Camel 4.22.2 and Camel Spring Boot 4.22.2 are on Central; the recipes release will follow the 4.22.2 release anyway. The Spring versions are not an issue: `camel-4.22.2` pins the same Spring Boot 4.1.1 / Spring 7.0.9 / Security 7.1.1 / Batch 6.0.5 as 4.23.0. _Claude Code on behalf of croway_ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
