romain-grecourt
commented
2 years ago See https://github.com/oracle/helidon-build-tools/issues/631
The fix that was implemented is graceful and none of the 2.x cli will break. We still need to investigate if we can customize the message to inform users that they need a 3.x cli to use Helidon 3.x
Investigate how to display a different upgrade messages for the same target cli version based on the current cli version.
E.g. The newest 2.x cli version will handle the 3.0 upgrade gracefully and will work by "ignoring" the latest 3.x versions. I.e it's going to work as-is 3.0.0 was never released.
However the older 2.x cli versions will resolve latest as 3.x and will break. Users will be either forced to supply a 2.x version explicitly or forced to upgrade because of the inability to work with "latest" versions.
We can use the exiting cli release notes as a fallback for older cli versions, and introduce a new set of properties that can be handled by newer cli versions.
Doing this will introduce additional complexity in our cli metadata data model, we may decide to handle upgrade messages for "broken cli versions" with the existing mechanism. The trade-off will be that newer 2.x cli versions that aren't broken will display a 3.x upgrade message that won't apply entirely. The message would be like "if you are on version xxx then yyy".