Consider modifying dependency management policy for WebJars Locator

[vpavic]

WebJars Locator (that is, webjars-locator-core) uses X.Y versioning format that doesn't quite align with the semver, however it seems that Spring Boot's dependency management policy treats the Y part as minor here as it didn't pick up 0.51 that was released about a week before Spring Boot 2.7.1.

I'm not really sure what's the policy for managing dependencies with similar versioning format but it seems that as things stand now Spring Boot will only upgrade WebJars Locator once per its own minor release, meaning 2.7.x will stick with 0.50 which isn't ideal. Could you consider doing an exception here?

[philwebb]

I'm not sure we should do this. There doesn't seem to be any guarantee that 0.51 is compatible with 0.50. In fact, applying this rule would suggest that 0.51 is compatible with 0.1.

[vpavic]

Just to confirm, your position on guarantees here is basically due to SemVer item 4?

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

[wilkinsona]

Not from my perspective. It could be 1.1 and 1.51 and Phil's reasoning would stand.

[vpavic]

How come, if this is about backwards compatibility guarantees? Minor should by definition be backwards compatible.

[philwebb]

It's not clear to me if WebJars is following semver or not, but just thinking practically it seems to me that breaking changes are likely possible in a minor version bump. Looking at https://mvnrepository.com/artifact/org.webjars/webjars-locator it appears that there aren't really any patch releases. If we follow the logic that 0.51 is compatible with 0.50 backwards then 0.51 must also be compatible with 0.1.

[vpavic]

Alright, I'll try reaching out to WebJars to see if they're willing to adopt SemVer.

[philwebb]

That would be helpful. It looks like the API is pretty stable so I imagine upgrades are most often back compatible. There have been examples in the past where deprecated classes have been removed so it seems there's no guarantee at the moment.

[vpavic]

I've opened webjars/webjars-locator-core#86.

[jamesward]

Hi all! Thanks for all your great support of WebJars in Spring. :)

A few thoughts...

1. (I might be wrong about all this) I think we should consider getting Spring off of webjars-locator-core because the primary feature of webjars-locator-core is about classpath scanning which a) doesn't use Spring's mechanism b) may not be compatible with Spring Native c) has performance overhead. We may still need something from WebJars that can handle resolving the version-less paths but that could be pulled out of webjars-locator-core to a much smaller library.
2. I've been lazy about learning SemVer stuff because I've felt if it can't be automated (like Elm does) then I'm not interested in investing the energy. Maybe there is now a Maven plugin that can automate it for me? If so I have no problem doing SemVer otherwise I'll probably continue being lazy.

[wilkinsona]

Thanks, @jamesward.

We added dependency management for webjars-locator in #3892 and switched to webjars-locator-core in #12060. Boot itself doesn't depend on it but I think we added the dependency management as a convenience for users of Framework's WebJarsResourceResolver. The resolver uses org.webjars.WebJarAssetLocator and therefore requires webjars-locator-core.

FWIW, we don't follow strict SemVer ourselves. We aim for patch releases (third digit) to be drop-in replacements, minor releases to be easy to adopt, and major releases to potentially take a bit more effort. We only consume patch releases of third-party dependencies in our patch releases in a best effort to be a drop-in replacement. Perhaps with a policy like this, automation wouldn't be necessary?