Clojurians Log v2

That sounds very dangerous and I hope no one really does that on purpose, as SNAPSHOT is meant to be magic by design and is a constantly moving target 🙂

The timestamp in SNAPSHOT dependency’s name is meant for caching mechanisms so that one doesn’t end up in constantly updating deps loop; Maven’s own default is updating SNAPSHOTs daily at most, and in most private repos I’ve worked with each artifact has been limited to only three latest SNAPSHOTs.

Folks using snapshots that want a stable build do depend on timestamped versions on purpose, to avoid a constantly moving target. the SNAPSHOT version is a mutable pointer, but the underlying repo shouldn't be mutable.

That’s not part of Aether though 🙂 To be clear, it has never been specified, but SNAPSHOTs have always been considered garbage of sorts in the larger ecosystem so they’re cannot be used as part of eg. repeatable builds.

A potential save for this situation though is that with build tools and clj/deps.edn a Clojure specific project type could be defined, which allows making these assumptions explicit in Maven compatible way; it seems the community is going into that direction anyway, especially since the build tools resolve order is different from Maven itself, so this looks more like a bubbling of new management format and model comparable to eg. npm, which shares quite a few things with Maven/Aether but is its own beast, especially in the version range syntax and behavior.

If that ever was an issue, Clojars could implement automatic short retention to the SNAPSHOT artifacts anyway and the S3 bucket would self-clean over time… 🙂

such retention can be done per bucket, per path and per file even

Thanks @suomi.esko! Our policy has been to not purge snapshots ever, since that would break builds that were dependent on the timestamp version of a snapshot.

Several projects do that, and it isn't an issue. The incoming network + s3 storage costs are dwarfed by the outgoing network costs, so feel free.

Thanks for asking!

Thank you!!