All nice ideas, but let's go back to a real usecase:
Let's assume we're having an issue with componentX-1.4
If you weren't one of the testers, then this dependency was pulled from
Maven Central. You can check out the code as specified in the tag, etc.
etc. No issues here.
But if you were one of the testers you must be sure that you're not using
the staged version anymore, but the one from Maven Central. When reusing
version numbers due to unsuccessful staged versions, you can only confirm
it by comparing the *revisions* of both componentX-1.4
I think somehow (the rootcause of) MNG-5181 is related: if you're using an
artifact originally from a staging repo and that repo has disappeared, the
build must fail. You are forced to clean up these staged artifacts, so
they are pulled from Maven Central. Only this way your local build is the
same as any other developers build.
As said before: - the actual release is the one in the dist-folder
- tags are just an easy way to refer to a certain revision.
- so if you want to be 100% sure you're checking out the correct source,
use revisions and not tags (which means revision must be set during
packaging, e.g in the manifest file).
Robert
Op Sun, 02 Jun 2013 22:43:02 +0200 schreef Benson Margulies
<[email protected]>:
I would consider it delux if the release plugin were enhanced to
support a more sophisticated mapping between artifact versions and
tags -- as per Kristian, wouldn't it be cool if it could iterate over
tags while repeating itself on customer-visible release numbers? I'd
help to code this is we had a collective understanding of how we
wanted it to work.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
