|
| 1 | +# Maven Version and tracking of versions released from the reference implementation |
| 2 | + |
| 3 | +## Context and Problem Statement |
| 4 | + |
| 5 | +Releases of this implementation track releases of the reference implementation. For each release of the reference implementation, there may follow a corresponding relase of this implementation with the same number as the reference implementation, allowing for additional metadata to version multiple releases of this implementation that track the same release of the reference implementation. |
| 6 | + |
| 7 | +## Considered Options |
| 8 | + |
| 9 | +- Simple number qualifier (0.1.32-0, 0.1.32-1, ...) fails on a subtle but important point: 0.1.32-0 is treated identically to 0.1.32 by Maven (trailing zeros are normalized away), and bare numeric qualifiers are pre-release semantics. Your "first release" would sort before the upstream bare version. |
| 10 | + |
| 11 | +- Java and number in the qualifier (0.1.32-java.N |
| 12 | + |
| 13 | + - java is an unknown qualifier that sorts correctly and accurately describes what it is — the Java-ecosystem release of this version. |
| 14 | + |
| 15 | +- sp and number in the qualifier (0.1.32-sp.N) |
| 16 | + |
| 17 | + - sp is a known Maven qualifier with a specific semantic ("service pack"), which is slightly misleading since your -java.0 isn't a service pack — it's the primary release. |
| 18 | + |
| 19 | +My recommendation, with the test results backing it up: 0.1.32-java.0, 0.1.32-java.1, 0.1.32-java.2. It passes every constraint you stated, is accepted by Sonatype (arbitrary string, not ending in -SNAPSHOT), and is self-documenting. The only thing left to validate empirically is actually uploading one to the portal — but nothing in Sonatype's published requirements would reject it. See below for empirical validation. |
| 20 | + |
| 21 | +## Decision Outcome |
| 22 | + |
| 23 | +Choose option "Java and number in qualifier". |
| 24 | + |
| 25 | +## Supporting information |
| 26 | + |
| 27 | +Output from experiment to publish an artifact with GAV `io.github.edburns:helloworld:0.1.31-java.0`: |
| 28 | + |
| 29 | +Everything looks healthy. Here's the status: |
| 30 | + |
| 31 | + - ✅ GPG signing succeeded (no passphrase errors this time) |
| 32 | + - ✅ Upload to Central succeeded — deployment ID |
| 33 | + e8192af5-769d-4cd3-a6d9-5fc38b4dbf10 was accepted |
| 34 | + - ✅ Authentication is working — all status checks return successfully |
| 35 | + - ⏳ State: publishing — Central accepted the bundle and is propagating it. |
| 36 | + The plugin is polling repeatedly (27+ checks so far), waiting for state to |
| 37 | + change to published. |
| 38 | + |
| 39 | + This is normal. Maven Central publishing can take 5–30 minutes to transition |
| 40 | + from publishing → published. The waitUntil=published setting in the POM |
| 41 | + means Maven will keep polling until it completes. Just let it run. |
| 42 | + |
| 43 | +> Given that the purpose of this exercise was to test your assertion that a GAV with a Version such as this one would be valid to publish to Maven central , can we already conclude this is a true assertion? |
| 44 | +
|
| 45 | +- Yes. The version 0.1.31-java.0 has already passed Maven Central's |
| 46 | + validation. The publishing state means Central accepted the bundle — |
| 47 | + including its GAV — and is now replicating it to mirrors. If the version |
| 48 | + were invalid, it would have been rejected during validation before entering |
| 49 | + the publishing state. |
| 50 | + |
| 51 | + So yes, the assertion holds: Maven Central accepts versions with dots inside |
| 52 | + the qualifier segment (e.g., 0.1.31-java.0). |
| 53 | + |
| 54 | +## Related work items |
| 55 | + |
| 56 | +- https://devdiv.visualstudio.com/DevDiv/_workitems/edit/2766089 |
0 commit comments