Conversation
Because I have no idea why it would fail
| # clear what each component means. For example, v0.6.2 precedes v0.6.2.1 through v0.6.2.4, | ||
| # and while some release notes include only security and/or bug fixes, v0.6.2.1 apparently | ||
| # also includes new features. So... who knows what anything means. | ||
| version = v"0.62.4" # upstream version is 0.6.2.4 |
There was a problem hiding this comment.
So what do you do if they ever go to 0.6.10, or 0.62.0 ?
Maybe unlikely (I don't know the project), but if you do custom versions, might as well go all the way and e.g. do what we do in several other JLLs with similar issues (e.g. for Singular): we multiply some of the parts by 100. So e.g. we might map 1.2.3p4 to something like 1.203.400 (we use .400 instead of .4 because it is handy when one has to make tweaks to the recipe, and if one is using a custom rule for translating the versions anyway.
So here I'd suggest 0.602.400
Of course that'll still break if they increment their version components enough, but the probability is quickly dropping (and you can add more 0s if you consider it a plausible scenario).
Anyway: this is not a blocker, just for your consideration.
There was a problem hiding this comment.
I appreciate the suggestion! I figured what I have here is reasonably safe because it looks like their next version will be 1.0 rather than another 0.6. Of course it's not impossible that they'd continue to make 0.6 patch releases (or further 0.x releases) but I figured the probability of a conflict arising in practice with this configuration was vanishingly small. I don't feel strongly though, so if it's better to adopt a pattern that's more consistent with other JLLs, that's fine with me.
Specifically the OpenIDC maintenance fork, v0.6.2.4.