Hi all, after some discussions with colleagues it turns out that it’s not quite as dramatic as I first throuhgt. So first I thought the commit hash was some way to address one fixed SNAPSHOT version via some mechanism I just didn’t know yet, but it turns out to be a lot simpler …. It produces a SNAPSHOT for version “2.5.2-a4398bf“ … so it’s an artificial version for which then again 3-5 SNAPSHOTS will be keept.
Seems it’s some shorthand version of inofficially releasing things without actually releasing them. So it’s still not ideal, as the referenced artifacts will never go to Maven Central and could cause problems with the one or the other user, I don’t see it as an immediate threat. Chris Von: Christofer Dutz <[email protected]> Datum: Mittwoch, 13. September 2023 um 11:01 An: [email protected] <[email protected]> Betreff: Ratis SNAPSHOT versions in our latest release ... Hi, I’m currently working on resolving some of the dependency version issues we are having. Mostly people will not have noticed, but currently we’re pulling in up to 4 different versions of a jar in our build. This can cause many extremely hard to spot problems. While trying to fix a problem with metrics-core in version 4.2.7 but pulling in on older version in Ratis I noticed us using: <ratis.version>2.5.2-a4398bf-SNAPSHOT</ratis.version> This is extremely problematic. Currently the Apache Nexus server only keeps 5 SNAPSHOT versions and then deletes old ones. This means that we regularly have to bump the SNAPSHOT version of Ratis. This got me thinking and I checked the release branch for the 1.2.x branch. Here we’re using the same. The problem with using SNAPSHOTS on master is not that severe, but using them in releases it very problematic. I guess we’ll only be able to build our last release for a few more days/weeks and then it will no longer be buildable. Are we relying on things in Ratis, that are not yet released? We should probably encourage the Ratis folks to head for a new release (Ideally with my latest Ratis-PR merged). Chris
