Simon Kitching wrote:
So to summarise, here are the options I see:
A: replace bad 1.0 jar with good 1.0 jar
B: rename bad 1.0 jar, do NOT provide any commons-cli-1.0.jar
C: leave bad 1.0 jar as-is
Here's my opinion:
A: -0
B: +1
C: -0
A: +1
B: -1
C: -0
Absolutely should be A (using the intact version from the binary
distribution - I assume this exists?), but still produce 1.0.1 as the
recommended latest release which will be less confusing.
There are too many levels at which this could have been propogated to be
able to ensure the new version will get out. Some people have stored it
as 1.0 in their own company internal repositories and won't pick up the
change either. IMO, A harms the least people (breaking a build harms
everyone, exposing them to a theoretical incompatiblity is much less
likely).
While admittedly it is harder to troubleshoot the incompatiblity
scenario, in this specific case are there any known incompatibilities?
I inadvertently discovered this some time back as I checked out the 1.0
tag to debug problems I was having with it, and when stepping through
the code found the lines didn't match up. I assumed at the time someone
had mucked up the release process of the original, not that it had been
overwritten.
Unfortunately, I still had the same problems with the version built from
the tag source, and went back to 1.0-beta-2 which works better for me
but is also an unknown point in time snapshot. I can detail this more in
a separate email if there is actually a CLI-1 maintainer, but I assumed
I would need to try out 2.0.
The real solution here needs to be better repository management to avoid
ever violating the integrity of a release. At Maven we are working on
tools for this. But since this can happen anyway (both inadvertantly and
maliciously), we are also considering "compare my repository to a
canonical source" integrity checks too. This could involve checking the
local sha1 against the local artifact and then checking that sha1
against the remote sha1 during a build, or doing a pass over the entire
repository to do the same thing.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
