The "Spring Boot 3.2" card doesn't quite make sense, its title cites … #75
Conversation
…a minor version target but the chart includes a "patch" section. Incrementing a patch versions will never result in getting to a new minor version. There isn't a conversion factor like 10 patch bumps -> 1 minor bump. A patch version bump and a minor version bump are qualitatively different. To make this make sense I am updating the title of the card to cite the patch version target. Additionally, I am improving the display to determine the spring boot version based on the version of spring-core, rather than the version of spring-boot. This is because libraries used by spring boot applications might benefit from the upgrade recipe without themselves taking a dependency on spring-boot itself. These currently fall through the cracks, showing as "complete" even if they are based on a very old version of spring and do need to be upgraded.
|
But does it not make sense that they fall through the cracks if the goal is to upgrade boot specifically? Regarding the patch version, it was not added because otherwise we need to keep it in sync with the recipe. Perhaps we can name it |
|
@pstreef no a library built on old springframework will still need to be upgraded before spring-boot applications can use it. There is no advantage to us or our users if we make it look like there is less benefit to running the upgrade recipes than there actually will be. |
That does assume that a repo with spring framework is a library and it will be used by a spring boot application that we're upgrading. To be fair I think no one will complain if we do this (except me, in this comment, I will stop now!) |
| }, | ||
| { | ||
| "name": "version", | ||
| "value": "3.2-3.2.2" | ||
| "value": "6.1.1-6.1.5" |
There was a problem hiding this comment.
if 6.1.6 or 6.2 comes out, repos using it will be marked as non compliant
There was a problem hiding this comment.
No anything which isn't covered by one of these gets marked as "complete". It's also the same situation we're in already with spring-boot if they were to release new versions.
…a minor version target but the chart includes a "patch" section. Incrementing a patch versions will never result in getting to a new minor version. There isn't a conversion factor like 10 patch bumps -> 1 minor bump. A patch version bump and a minor version bump are qualitatively different.
To make this make sense I am updating the title of the card to cite the patch version target.
Additionally, I am improving the display to determine the spring boot version based on the version of spring-core, rather than the version of spring-boot. This is because libraries used by spring boot applications might benefit from the upgrade recipe without themselves taking a dependency on spring-boot itself. These currently fall through the cracks, showing as "complete" even if they are based on a very old version of spring and do need to be upgraded.