Comment From: dreis2211

@philwebb Have you started investigating already? Otherwise I would give it a go - I have a pretty good idea already what might be going on here.

Comment From: dreis2211

A quick check confirmed my idea - the behaviour is caused when using same-minor-version as upgrade policy and Jersey (among others) is only using the major and minor part. Technically it's not semantic versioning I would say, but I'm not sure what it is...

I'm not sure if this is expected for Jersey. If not, I could think of providing a way to override the upgrade policy per library if needed. E.g. like this:

    library("Jersey", "2.33") {
        policy = "same-major-version" // That's the new bit
        prohibit("[3.0.0-M1,)") {
            because "it uses the jakarta.* namespace"
        }
        group("org.glassfish.jersey") {
            imports = [
                "jersey-bom"
            ]
        }
    }

Let me know if I can help.

Comment From: philwebb

I'm not sure if we should change the policy or not. I think we might want to keep it as is for now. We're probably missing something in our processes to ensure we pick upgrades up before we cut an RC.

Comment From: philwebb

Actually, it looks like we cut RC1 on Apr 15 and the Jersey release was on Apr 20 so perhaps the process worked fine and we just got unlucky.

Comment From: dreis2211

I'm also getting the unfortunate timing vibe, but for completeness reasons here are the versions that at least currently point to only major.minor schemed versions. If you want to discuss this any further in the team. Some of them have proper semantic versions in between, some of them don't. But none of them seem so important that it would justify a per-library override of the upgrade policy.

Lib Version Notes
Commons Codec 1.15
Commons Pool 1.6 Can be ignored I guess
Hamcrest 2.2
InfluxDB Java 2.21
Javax JsonB 1.0
Javax Money 1.1
Javax WebSocket 1.1
Jersey 2.33 2.34 would be available
JMustache 1.15
JSTL 1.2
Maven AntRun Plugin 1.8 3.0.0 was released on Apr 15
SnakeYAML 1.28
WebJars Locator Core 0.46

Comment From: snicoll

Actually, it looks like we cut RC1 on Apr 15 and the Jersey release was on Apr 20 so perhaps the process worked fine and we just got unlucky.

That's right, bomr works just fine as far as I can tell.

The problem is these libraries have an unusual versioning scheme where it isn't obvious if the release is a bugfix or a minor release. Perhaps an override of the policy with some extra context would be helpful, as @dreis2211 suggested.

Comment From: wilkinsona

FWIW, Jersey does release patch versions, but only occasionally. For example, there was a 2.30.1 release and 2.22.x got as far as 2.22.4.

Comment From: philwebb

After some discussion today we feel that we should continue with our current policy. We're worried that changing things for a few libraries would be confusing. We're also worried that any breaking changes made in a minor release of a third-party library would increase our maintenance burden.