Repository navigation
Releases in lockstep #48
Description
Activity
Seems versions with leading
vviolate JPMS "module version" spec?
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java#L957-L1003Why was this
vprefix added to versions in the first place? I mean, it seems constant and does not add (nor take) anything from selectivity or ordering... but sadly JPMS dislikes it.Also, my feeling is that all these tiny projects would benefit a lot from some common parent POM (as they are basically 100% same thing sans dependencies).
Where could be craft one for them? But I personally think pushing them all together into one reactor would really be the simplest...
It was just a convention from protocol labs ecosystem. Fine to remove it
Reacted by Tamas CservenakOk, the
vprefix will be removed (clashes withjavac --module-versionoption as can be seen above.Then we need
1.3.0release of java-multibase from master, I guess? What are plans, where to publish? jitpack as before or Central?I've pushed 1.3.0 and triggered jitpack
Reacted by Tamas Cservenakmultiformats/java-multihash#54 read for review and possible merge, to be followed by git-blame ignore...
last PR for multihash multiformats/java-multihash#55 and I suggest multiformats/java-multihash#52 as well, and then release 1.3.7 (or 1.4.0? I don't know what changes are)
multihash 1.4.0 is out now
Reacted by Tamas Cservenaknext ipld/java-cid#45
ipld/java-cid#46 is last and a release, 1.4.0?
I just noticed cid has the same name issue
and multihash too
bummer, sorry for that.... what now? should we do .1 releases to fix this? As far maven and JAR goes, it really does not matter ad
project.nameis mostly used in reporting...1 remaining item
If maven doesn't care. I say leave it.
merge them, and will get out on next .1 release, issues, git, these are important metadata (not only for consumers, but for anyone curious "from where this comes" for example)
Reacted by Dr Ian PrestonIf everything ok, ipld/java-cid release, 1.4.0?
Ok that's out now
Ok, next is multiformats/java-multiaddr#33
And hopefully last multiformats/java-multiaddr#34
And if all fine, java-multiaddr 1.5.0 release? And if that happened, this issue can be closed and we are back to https://github.com/ipfs-shipyard/java-ipfs-http-client
Okay that's out now too. Thanks for all your help.
Reacted by Tamas CservenakOk, we seems to be fine, few remarks:
- I see @ianopolous left all POMs with release version. This is dangerous and not recommended as if someone works on the packages,
mvn installwill replace the JAR in local repo, and given it is release version, will never figure out it is altered locally (pull the "real one" from remote). Hence, post release step by adding +.1-SNAPSHOT is recommended. - I messed up some metadata for some package (copy pasta error), fixes are merged and will go out on next .1 release of corresponding packages
Aside of these, I say is fine to close this issue, we had the release spree done successfully, next pending change is
ipfs-shipyard/java-ipfs-http-client#269- I see @ianopolous left all POMs with release version. This is dangerous and not recommended as if someone works on the packages,
Thanks, I've done that. I view that as a deficiency of maven's design.
Me too, but we cannot fix that even in Maven 4 (as it must offer Maven 3 compat)...
My thoughts about this topic https://maveniverse.eu/blog/2025/11/09/maven-local-repository/The "fix" can be split repository (that keeps separately cached and locally-built artifacts), but as we saw, split repository is "too invasive". Hence I did Mimir + regular local repo nuking is fix for me.
What are your thoughts on bazel?
I never used Bazel on any daily basis, I don't have much knowledge about it. This is more a @vorburger question IMO.
Seems we will need to do this, but there is a problem: I had to remove
vprefixes from version as it caused issues: