Skip to content

Conversation

@jjohannes
Copy link
Member

Resolve #188

@jjohannes jjohannes added this to the 2.3 milestone Apr 27, 2025
@jjohannes jjohannes merged commit b968d0f into main Apr 27, 2025
6 of 7 checks passed
@jjohannes jjohannes deleted the bouncycastle-lts branch April 27, 2025 08:59
@Vampire
Copy link
Contributor

Vampire commented Apr 27, 2025

Hi there, are you sure just using latest version resolution is the right thing to do here? The lts versions will always be higher than the non-lts versions if I got it right.

2.73.x lts is based off 1.73 and only gets non-breaking changes. So if one dependent declares lts 2.73 and another needs breaking changes of the 20 years younger 1.999, it will resolve to old lts version and break.

@jjohannes
Copy link
Member Author

Thanks for the clarification. Interesting versioning scheme....
IIUC, this means one could say, from the capability perspective:

  • 2.73 corresponds to the 1.73
  • 1.80 is therefore "higher" than 2.73 and the better "best guess" when doing select highest version

It might still not be always what the user wants, but that's the general issue that "select highest version" is only a "best guess" so that there is a default strategy. (See #185 for possibly changing something in the next major release.)

I made an adjustment that aligns the 1.x and 2.x version numbers in the Bouncy Castle rule: #226

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Extend Bouncycastle rule to support lts artifacts

3 participants