maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject Re: [VOTE] Should we respin CANCELLED releases with the same version number?
Date Mon, 03 Jun 2013 17:49:19 GMT
Now the issue with componentX-1.4 that you wan to test is one that only
shows up behind your corporate proxy, and you have a system set up with the
failing case and you dare not change anything...

So you add the staging repo to your mirror, run the test case, and drop the
test artifact from the mirror as fast as you can... (Because creating a
separate mirror would require changing the test setup and resulting in
re-resolution again)

The thing is that the test is a long test... And now you don't know who
else has got that invalid componentX-1.4 (because your test is still
failing) and when the fixed componentX-1.4 is released you may find a
nightmare tracking it down again.

Somewhat contrived some might say, but that is the use case where this s
more critical

On Monday, 3 June 2013, Robert Scholte wrote:

> 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 <
>  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:
>> For additional commands, e-mail:
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Sent from my phone

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message