Version snapshots by date ?

Tom Zeller tzeller at dragonacea.biz
Wed Dec 11 12:03:57 EST 2013


> Deployed snapshots in Nexus are already fully-qualified. See, for example:
>
> https://build.shibboleth.net/nexus/content/repositories/snapshots/net/shibboleth/idp/idp-attribute-api/3.0-SNAPSHOT/

The uniqueVersion per artifact is what I am considering not doing.
(see last comment)

> I believe the normal approach would be to build a binary distribution of the testbed as the primary way people would access it. This would include all of the dependencies (in particular the particular upstream snapshots as JARs) so it wouldn't break later.
>
> Either that, or cut proper interim releases, tagged and deployed as such.

If we cut interim- or pre-releases, the versions are unclear to me.
Hence I was thinking Major.Minor-SNAPSHOT-YYYYMMDD rather than
-alpha-x or something.

> ...I think you're trying to stretch "snapshot" to mean something that it isn't intended to mean, and that would likely cause issues. In particular, Nexus knows that actual snapshots expire, so it's fine to have one for every day because they gradually vanish again. Pushing something other than a "-SNAPSHOT" version to Nexus would, I think, mean that we were pushing something that was not a Maven snapshot, which would imply (a) that it would have to go to the release repository (b) Jenkins would need release credentials (c) they would never go away but accumulate forever.

I was thinking that deploying nightly snapshots would be okay because
we would not need them to stay around forever, just long enough to
allow third-party developers to not have their stuff break too often.

> I think that's pretty far off the beaten track, and as you know I believe in staying firmly on the path in these matters. There are Spiders in the woods.

Right. Maven 3 dropped support for
<uniqueVersion>false</uniqueVersion>, because non-unique snapshots are
a "bad idea". I get that.


More information about the dev mailing list