I agree with Stephen and Brett. We *have* to do A, IMHO. The "good" jar is what was released. We should not be distributing non-released jars from java-repository at all, much less non-released jars named to look like releases.
My votes are A: +1 B: -0 C: -1 Brett, Are there any tools that we can use now to check md5's in java-repository against releases on dist to make sure there are no other cases like this? Phil On 7/16/05, Brett Porter <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
