> If these are being released into Central - then they *will* never change.
> They are Golden.
> Prior to getting their, e.g. during the voting process, these jars are
> released
> into a staging area.
> You are invited to try those jars from the staging area to ensure they dont
> have regression issues etc.
That's what I would like to do.
> If you do this then you generally delete your local m2 cache
> (~/.m2/repository) or you use a new settings.xml file that points to a
> different location.
Meanwhile these are in all the caches of the MRMs and it needs more work than
would ideally be needed (if you want to widen testing to more of the community)
> You would not normally use an MRM in this scenario as the staging jars are
> not yet Golden.
This definition of release contradicts mavens definition.
A release is something that has no -SNAPSHOT (or timestamp) at the end of
its version.
Thus these are releases even if they do not make it onto central (and deleting
nexus stages after allowing any maven to consume from it is a bad thing and
imho one of the things that nexus pro really needs to improve on)
I am also well aware of how nexus staging works - and staging is not the issue,
reusing the same release version is the issue.
All this extra hand fudging would disappear if the versions where used where
unique e.g 1.0.0-1 vote fails next is 1.0.0-2.
But also how can I test it if I can't use it... (esp the maven-release-plugin!)
Most tests to be useful would be done in a CI environment with auto testing -
configuring different jobs to have different settings would be a PITA.
> If the release fail, then the staging areas are deleted and the process starts
> again. Nothing has happened to Central yet.
But the artifacts have been used elsewhere (even just testing is using it...).
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
