You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Torsten Curdt <tc...@apache.org> on 2005/07/06 09:05:13 UTC
Re: [CLI] two different versions of commons-cli-1.0.jar?
>>I could take care of pushing out the jar to
>>ibilio ...but I think we should have a proper
>>release or at least a tag for 1.0.1 then.
>
>
> Sorry, I don't understand this.
ibiblio# rm commons-cli-1.0.jar
#scp commons-cli-1.0.jar minotaur
#svn co https://.../CLI_1_0_1
#maven jar
#scp commons-cli-1.0.1.jar minotaur
...sync ...sync
ibiblio# ls
commons-cli-1.0.jar <-- the real 1.0!
commons-cli-1.0.1.jar
;-)
> The filename "commons-cli-1.0.jar" is now ambiguous. It could refer to
> either of two actual bunches of files. Updating the ibiblio one from the
> bad jar to the good jar is therefore pretty pointless; the bad jar is
> out there in circulation.
Sure ...but there is not much we can
do about it. Unfortunately maven will
not update the jar. People have to
remove it from their local .maven
cache.
...so if it breaks a project - it
only does on a fresh checkout.
But IMHO this is our problem only
to a limited extend.
What would happen if one of the
Apache mirrors would screw up like
this ...what would we do?
I think just let's fix it and make
an announcement on users.
WDYT?
cheers
--
Torsten
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Brett Porter <br...@apache.org>.
Phil Steitz wrote:
>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?
>
>
>
Henk maintains something across all of dist, however there is a chance
that if someone purposely redeployed with Maven that it was overwritten
with a new MD5 too - hence the reason Maven needs some more protection
built in.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2005-07-17 at 00:43 -0700, Phil Steitz wrote:
> 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.
Well, it looks like there is absolutely no consensus at all on this
issue. Opinions seem to be fairly evenly spread across all possible
actions.
However there does seem to be general consensus (though with some
dissenting voices) that a 1.0.1 release is a good idea.
So I've created a Wiki page for CLI describing the current situation and
that the resolution for the ibiblio jars is "under debate". I have also
modified the 1.0.1 proposed website to point people to the wiki for
further info; that means we have the *capability* to push out a 1.0.1
release without waiting for this debate to be resolved - if a release
vote passes.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Phil Steitz <ph...@gmail.com>.
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 <br...@apache.org> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Simon Kitching <sk...@apache.org>.
On Wed, 2005-07-20 at 13:54 -0400, Henri Yandell wrote:
> Scratch that. Brett pointed out that that may no longer be a valid question.
Has he??
>
> What's the current plan to fix this? Or is it a question of which
> plans to focus on?
>
> I assume the easiest (but painful to some set of users) would be:
>
> Rename ibiblio's 1.0 to 1.0-20040129.jar (or todays date, need to
> decide which would be best, 20040129 is the timestamp of the 1.0 on
> ibiblio currently).
> Deploy the real 1.0 to ibiblio.
> Add a README explaining the historical problem.
Well, the idea of releasing a 1.0.1 hasn't reached consensus so I'm
going to stop working on that.
As you say, the above approach may cause pain for some users. However I
would agree that the above is better than doing nothing. I can't summon
any enthusiasm for actually performing the above myself, but won't vote
against it if someone proposes formally to do this.
To modify ibiblio's setup I believe all that is necessary to do is to
log on to people.apache.org and rename/update files in directory
/www/www.apache.org/dist/java-repository/commons-cli
as described in section 8 of this document:
http://jakarta.apache.org/commons/releases/release.html
I would also suggest hacking the commons-cli website directly on the
people.apache.org server, ie at:
/www/jakarta.apache.org/commons/cli
to note that there was a problem with the 1.0 release and that people
should see the commons-cli wiki page at
http://wiki.apache.org/jakarta-commons/CLI
for more info. And then of course the wiki page should be updated to
reflect whatever action was taken.
Note that if changes are made to a jakarta website on people.apache.org
it may take a few hours to be replicated to the actual
jakarta.apache.org server. However the changes on people.apache.org
*can* be viewed immediately via fiddling with proxy settings as
described in section 10 here:
http://jakarta.apache.org/commons/releases/release.html
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2005-07-26 at 23:10 +0100, robert burrell donkin wrote:
> On Tue, 2005-07-26 at 23:56 +1200, Simon Kitching wrote:
> > On Tue, 2005-07-26 at 13:46 +0200, Stefan Bodewig wrote:
> > > On Mon, 25 Jul 2005, Brett Porter <br...@apache.org> wrote:
> > >
> > > > Thanks. I'm still in favour of putting the correct one from the dist
> > > > back.
> > >
> > > big +1
> >
> > Then I suggest that someone call a proper vote on doing this (this
> > thread isn't really a vote thread). The initial email should list the
> > exact tasks that are going to be done (see my recent email for a
> > suggested list).
i've posted a vote thread containing the only action required for
oversight. i attached the replacement vote with it since they would
probably need to be executed together.
i'm willing to start VOTE threads for the other proposals but i might
not be the best advocate:
it would be possible to roll a binary-only 1.0.1 without license worries
but i'm no longer so sure what this would achieve (but it's very
possible i missed the point)...
i would like to see the bogus jar made available as a dated snapshot but
i don't have karma...
simon: you've thought through the permutations carefully. i'd be
grateful if you could outline what other actions we could take that
might help users.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2005-07-26 at 23:56 +1200, Simon Kitching wrote:
> On Tue, 2005-07-26 at 13:46 +0200, Stefan Bodewig wrote:
> > On Mon, 25 Jul 2005, Brett Porter <br...@apache.org> wrote:
> >
> > > Thanks. I'm still in favour of putting the correct one from the dist
> > > back.
> >
> > big +1
>
> Then I suggest that someone call a proper vote on doing this (this
> thread isn't really a vote thread). The initial email should list the
> exact tasks that are going to be done (see my recent email for a
> suggested list).
>
> Once the vote passes that someone should then go ahead and do it.
most of the proposed actions require only lazy consensus. however, i
can't actually remove the jar just yet and a vote would tidy probably
tidy things up. i'll start this on another thread.
> > > If anyone has problems using the original 1.0 where it used to work,
> > > I suggest a 1.0.1 release can then be worked on.
> >
> > +1 again.
>
> I don't understand this at all. People have built against a
> snapshot-of-unknown-date mistakenly labelled 1.0. Building a 1.0.1 based
> on the 1.0 code won't produce something that can replace what they built
> against. And building a 1.0.1 based on HEAD won't produce something that
> can replace what they built against.
the original jar could be made available from ibiblio as a dated
snapshot provided that someone with ibiblio karma is willing to upload
it. i have no worries about the authenticity of the jar.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 26 Jul 2005, Simon Kitching <sk...@apache.org> wrote:
> I don't understand this at all. People have built against a
> snapshot-of-unknown-date mistakenly labelled 1.0.
True.
> Building a 1.0.1 based on the 1.0 code won't produce something that
> can replace what they built against.
I don't think that is what has been suggested.
> And building a 1.0.1 based on HEAD won't produce something that can
> replace what they built against.
So what can replace it? This should be the 1.0.1.
See, if people tell you I've built it against 1.0 and others download
1.0 - the real thing, not the jar from the ibiblio repo - the build is
going to fail. We need to ensure that our releases are consistent and
our full distributions really ought to be the reference point, not
what happened to get rsynced to some repository.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Simon Kitching <sk...@apache.org>.
On Tue, 2005-07-26 at 13:46 +0200, Stefan Bodewig wrote:
> On Mon, 25 Jul 2005, Brett Porter <br...@apache.org> wrote:
>
> > Thanks. I'm still in favour of putting the correct one from the dist
> > back.
>
> big +1
Then I suggest that someone call a proper vote on doing this (this
thread isn't really a vote thread). The initial email should list the
exact tasks that are going to be done (see my recent email for a
suggested list).
Once the vote passes that someone should then go ahead and do it.
>
> > If anyone has problems using the original 1.0 where it used to work,
> > I suggest a 1.0.1 release can then be worked on.
>
> +1 again.
I don't understand this at all. People have built against a
snapshot-of-unknown-date mistakenly labelled 1.0. Building a 1.0.1 based
on the 1.0 code won't produce something that can replace what they built
against. And building a 1.0.1 based on HEAD won't produce something that
can replace what they built against.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 25 Jul 2005, Brett Porter <br...@apache.org> wrote:
> Thanks. I'm still in favour of putting the correct one from the dist
> back.
big +1
> If anyone has problems using the original 1.0 where it used to work,
> I suggest a 1.0.1 release can then be worked on.
+1 again.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Brett Porter <br...@apache.org>.
robert burrell donkin wrote:
>we (torsten, stefan, peter and others) talked about this at apachecon.
>we really need to remove the (unofficial snapshot) commons-cli-1.0.jar
>from the java-repository. i plan to do this soon. i'll post a summary to
>repo and pmc before acting. i will also prepare some kind of
>announcement and post it widely.
>
>
Thanks. I'm still in favour of putting the correct one from the dist back.
>this is going to cause difficulties for users. as discussed previously,
>they will have been building and using a snapshot rather than the
>correct release. their builds may well be broken. i would prefer to have
>some kind of plan in place to try to reduce the damage.
>
>
If anyone has problems using the original 1.0 where it used to work, I
suggest a 1.0.1 release can then be worked on. I don't expect to see
much of this problem as from what I could tell the changes were not a
highly used part of the API.
>it would probably be easier to work out a plan by IRC (if people are
>available) than continue this long email exchange. i'm not sure where
>the maven folks hang out these days so hopefully brett will be able to
>jump in with a suggested venue and time.
>
>
I'm around quite a bit, except that I've got a couple of things to do
tonight and tomorrow morning. Other than that, 9am till midnight
Australian Eastern is fine by me. I hang out on ASF channels at
freenode, but am not aware of a Jakarta one. #maven at irc.codehaus.org
would be fine too, and has the advantage of being available behind
firewalls at http://irc.codehaus.org/. Torsten and I had a (text) chat
on Skype the other day too. Whatever suits everyone best...
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by robert burrell donkin <rd...@apache.org>.
we (torsten, stefan, peter and others) talked about this at apachecon.
we really need to remove the (unofficial snapshot) commons-cli-1.0.jar
from the java-repository. i plan to do this soon. i'll post a summary to
repo and pmc before acting. i will also prepare some kind of
announcement and post it widely.
this is going to cause difficulties for users. as discussed previously,
they will have been building and using a snapshot rather than the
correct release. their builds may well be broken. i would prefer to have
some kind of plan in place to try to reduce the damage.
it would probably be easier to work out a plan by IRC (if people are
available) than continue this long email exchange. i'm not sure where
the maven folks hang out these days so hopefully brett will be able to
jump in with a suggested venue and time.
- robert
On Thu, 2005-07-21 at 10:30 +0100, robertburrelldonkin@blueyonder.co.uk
wrote:
> IMO there are two separate issues here which are in danger of becoming a
> little confused: what needs to be done about the jar in the apache java
> repository and what can be done to limit the impact of the problem on
> users of maven.
>
> the jar in the repository is not an official release and must be removed.
> the only reason this hasn't been done yet is that we need to understand
> the impact that this would have on users (which i think this thead has
> covered) and the best way to limit the impact on users of ibiblio and
> maven.
>
> > On Thu, 21 Jul 2005, Simon Kitching <sk...@apache.org> wrote:
> >> On Thu, 2005-07-21 at 09:43 +0200, Stefan Bodewig wrote:
> >>> Hi,
> >>>
> >>> Thorsten and Robert explained the situation to me during the BOF
> >>> yesterday, and I hope I have it right. Sorry I haven't followed it
> >>> that closely before.
> >>>
> >>> Is it true that the jar on ibiblio has never been an official
> >>> release?
> >>
> >> No, it was not a release. It's a snapshot from about 12 months after
> >> 1.0 was released.
> >>
> >>> If so, there is no point in renaming it, remove it.
> >>
> >> If it had been up for just a week or so, I would agree. However it's
> >> been available for well over a year. That means there is a whole lot
> >> of code out there that may have been built against it, run through
> >> the corporate QA procedure then shipped as an official product to
> >> customers. Deleting all trace of it could make thinks awkward for
> >> people....
> >
> > Simon, I do understand all that. But legally we only have two
> > options. Make it an official release by following our own procedures,
> > which does require to make it ASL 2.0 - or remove it. There is no
> > other option.
>
> the jar has the wrong name and is in the wrong place.
>
> however, i have no reason not to trust the reliability of the jar and so i
> see no problem in uploading a copy to an appropriate place with an
> appropriate name. AIUI, this means ibiblio.
>
> >> Person A builds some code depending on 1.0. They strike a bug, and
> >> ask person B to look into it.
> >
> > If A uses the jar from the local repo, nothing we do on the server is
> > going to change that. If we rename the jar, person A will still use
> > the bad version named 1.0 from the local repo.
>
> this is indeed a bad situation. however, there is flexibility about the
> contents of the ibiblio repository. AIUI the maven team have dealt with
> similar situations before and i think the best thing would be to make sure
> the jar is preserved locally and let brett handle the maven issues.
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by ro...@blueyonder.co.uk.
IMO there are two separate issues here which are in danger of becoming a
little confused: what needs to be done about the jar in the apache java
repository and what can be done to limit the impact of the problem on
users of maven.
the jar in the repository is not an official release and must be removed.
the only reason this hasn't been done yet is that we need to understand
the impact that this would have on users (which i think this thead has
covered) and the best way to limit the impact on users of ibiblio and
maven.
> On Thu, 21 Jul 2005, Simon Kitching <sk...@apache.org> wrote:
>> On Thu, 2005-07-21 at 09:43 +0200, Stefan Bodewig wrote:
>>> Hi,
>>>
>>> Thorsten and Robert explained the situation to me during the BOF
>>> yesterday, and I hope I have it right. Sorry I haven't followed it
>>> that closely before.
>>>
>>> Is it true that the jar on ibiblio has never been an official
>>> release?
>>
>> No, it was not a release. It's a snapshot from about 12 months after
>> 1.0 was released.
>>
>>> If so, there is no point in renaming it, remove it.
>>
>> If it had been up for just a week or so, I would agree. However it's
>> been available for well over a year. That means there is a whole lot
>> of code out there that may have been built against it, run through
>> the corporate QA procedure then shipped as an official product to
>> customers. Deleting all trace of it could make thinks awkward for
>> people....
>
> Simon, I do understand all that. But legally we only have two
> options. Make it an official release by following our own procedures,
> which does require to make it ASL 2.0 - or remove it. There is no
> other option.
the jar has the wrong name and is in the wrong place.
however, i have no reason not to trust the reliability of the jar and so i
see no problem in uploading a copy to an appropriate place with an
appropriate name. AIUI, this means ibiblio.
>> Person A builds some code depending on 1.0. They strike a bug, and
>> ask person B to look into it.
>
> If A uses the jar from the local repo, nothing we do on the server is
> going to change that. If we rename the jar, person A will still use
> the bad version named 1.0 from the local repo.
this is indeed a bad situation. however, there is flexibility about the
contents of the ibiblio repository. AIUI the maven team have dealt with
similar situations before and i think the best thing would be to make sure
the jar is preserved locally and let brett handle the maven issues.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 21 Jul 2005, Simon Kitching <sk...@apache.org> wrote:
> On Thu, 2005-07-21 at 09:43 +0200, Stefan Bodewig wrote:
>> Hi,
>>
>> Thorsten and Robert explained the situation to me during the BOF
>> yesterday, and I hope I have it right. Sorry I haven't followed it
>> that closely before.
>>
>> Is it true that the jar on ibiblio has never been an official
>> release?
>
> No, it was not a release. It's a snapshot from about 12 months after
> 1.0 was released.
>
>> If so, there is no point in renaming it, remove it.
>
> If it had been up for just a week or so, I would agree. However it's
> been available for well over a year. That means there is a whole lot
> of code out there that may have been built against it, run through
> the corporate QA procedure then shipped as an official product to
> customers. Deleting all trace of it could make thinks awkward for
> people....
Simon, I do understand all that. But legally we only have two
options. Make it an official release by following our own procedures,
which does require to make it ASL 2.0 - or remove it. There is no
other option.
> Person A builds some code depending on 1.0. They strike a bug, and
> ask person B to look into it.
If A uses the jar from the local repo, nothing we do on the server is
going to change that. If we rename the jar, person A will still use
the bad version named 1.0 from the local repo.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Simon Kitching <sk...@apache.org>.
On Thu, 2005-07-21 at 09:43 +0200, Stefan Bodewig wrote:
> Hi,
>
> Thorsten and Robert explained the situation to me during the BOF
> yesterday, and I hope I have it right. Sorry I haven't followed it
> that closely before.
>
> Is it true that the jar on ibiblio has never been an official release?
No, it was not a release. It's a snapshot from about 12 months after 1.0
was released.
> If so, there is no point in renaming it, remove it.
If it had been up for just a week or so, I would agree. However it's
been available for well over a year. That means there is a whole lot of
code out there that may have been built against it, run through the
corporate QA procedure then shipped as an official product to customers.
Deleting all trace of it could make thinks awkward for people....
>
> And overwrite it with the real one. No need for a new release no need
> for a license change.
>
> > Rename ibiblio's 1.0 to 1.0-20040129.jar (or todays date, need to
> > decide which would be best, 20040129 is the timestamp of the 1.0 on
> > ibiblio currently).
>
> What is that good for? Doesn't this send he message that this jar is
> a dated version of 1.0 - a released version?
If you think this name is misleading, then perhaps
commons-cli-1.0-screwup-20040129.jar
would be better? It has a certain je-ne-sais-quoi :-)
The thing is, if this jar is *deleted* it can never be rebuilt because
we don't know *exactly* what CVS code it came from. And as I described
above, there are potentially many products built between 20040129(?) and
the current date.
>
> > Deploy the real 1.0 to ibiblio.
As I described in an earlier email, this can lead to the following
scenario:
Person A builds some code depending on 1.0. They strike a bug, and ask
person B to look into it. Person B builds the code and can't duplicate
the problem. Reason: because person A has the "bad" version in their
maven cache while person B does not.
If the code in question has only *one* dependency, then maybe after a
few hours of debugging it might occur to B to check the website or wiki
for commons-cli. It would certainly be nicer if B simply got a compile
error: "commons-cli-1.0.jar cannot be found".
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Stefan Bodewig <bo...@apache.org>.
Hi,
Thorsten and Robert explained the situation to me during the BOF
yesterday, and I hope I have it right. Sorry I haven't followed it
that closely before.
Is it true that the jar on ibiblio has never been an official release?
If so, there is no point in renaming it, remove it.
And overwrite it with the real one. No need for a new release no need
for a license change.
> Rename ibiblio's 1.0 to 1.0-20040129.jar (or todays date, need to
> decide which would be best, 20040129 is the timestamp of the 1.0 on
> ibiblio currently).
What is that good for? Doesn't this send he message that this jar is
a dated version of 1.0 - a released version?
> Deploy the real 1.0 to ibiblio.
> Add a README explaining the historical problem.
+1
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Henri Yandell <fl...@gmail.com>.
Scratch that. Brett pointed out that that may no longer be a valid question.
What's the current plan to fix this? Or is it a question of which
plans to focus on?
I assume the easiest (but painful to some set of users) would be:
Rename ibiblio's 1.0 to 1.0-20040129.jar (or todays date, need to
decide which would be best, 20040129 is the timestamp of the 1.0 on
ibiblio currently).
Deploy the real 1.0 to ibiblio.
Add a README explaining the historical problem.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Henri Yandell <fl...@gmail.com>.
I'm finding out if we can release this as ASL 1.1, or if we have to do ASL 2.0.
Hen
On 7/18/05, Torsten Curdt <tc...@apache.org> wrote:
>
> > A clirr/jdiff support would be could to do.
> > Will try to do that once I am back online.
> >
>
> Ok, guys ...I've run clirr against the
> involved jars. Have a look yourself...
>
> http://people.apache.org/~tcurdt/cli/
>
> cheers
> --
> Torsten
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Torsten Curdt <tc...@apache.org>.
> A clirr/jdiff support would be could to do.
> Will try to do that once I am back online.
>
Ok, guys ...I've run clirr against the
involved jars. Have a look yourself...
http://people.apache.org/~tcurdt/cli/
cheers
--
Torsten
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Torsten Curdt <tc...@apache.org>.
>> 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.
That's also what I thought in the first place.
But I think Simon is right. Since we have no
direct notifier (which would be a cool thing
to add to maven. kind like a "message of the
day" as part of every repo you download from)
we might cause quite a few hours of wasted
energy.
Noone would expect such thing. All he sees
is that it compiles on that machine and doesn't
compile on the other one. A changed jar does not
sound like an obvious thing to take into account
when searching for the problem.
> While admittedly it is harder to troubleshoot the incompatiblity
> scenario, in this specific case are there any known incompatibilities?
A clirr/jdiff support would be could to do.
Will try to do that once I am back online.
> 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.
Actually there has even been some discussions
a while ago about a release of 2.0. Maybe it's
worth pushing that a little. 1.0 does feel a
bit rusty in some areas.
> 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.
Sounds like a good plan.
cheers
--
Torsten
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Brett Porter <br...@apache.org>.
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Simon Kitching <sk...@apache.org>.
On Fri, 2005-07-15 at 02:26 +0200, Torsten Curdt wrote:
> > Rob/Torsten, so what's the plan for this? Who's doing what etc?
> > Anything I can help make happen? Perms etc.
As noted in a separate email, an RC is up for review.
There is one question still to be decided though: do we *delete* the
existing 1.0 jar from ibiblio, or replace it with the right one.
I've argued for deleting it because otherwise projects that declare
dependencies on 1.0 will work differently when compiled on different
systems depending on what version (if any) is in the maven cache.
So person A can compile (getting the snapshot) and see a certain
behaviour. Person B can compile the same software on a different machine
(getting the correct 1.0) and see different behaviour. Very confusing.
I would rather see person B get an error message saying that
commons-cli-1.0.jar cannot be found on ibiblio. They will then go to the
cli website and see why, and fix the project to depend on 1.0.1 instead.
Ok, deleting the ambiguous 1.0.jar file doesn't completely solve the
problem for our hypothetical A and B if they both already have the jar
cached in maven's repo, but have different versions. Still, deleting
will warn as many people as possible of this issue.
Replacing the bad 1.0 with the good one at this point is probably not a
good idea either. Again, we have the issue where someone has a working
product based on the snapshot (under the illusion it is the real
release). By replacing this with the "real" 1.0 we could potentially
break their product if they depend on behaviour present in the snapshot
but not the real release. Instead, removing the bad 1.0 will alert them
to resolve the issue by hand.
Actually, we should probably continue to make the bad 1.0 available but
under a different name for the use of people who want to continue using
it. I'd be happy to go in and rename the jar right now, to something
like
commons-cli-1.0-snapshot.jar
if there is agreement on that.
The alternative is to leave the bad 1.0 there on the principle that
it hasn't actually broken anyone's code that we are aware of (just
confused a few people who spotted that it wasn't the real 1.0 release).
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
Comments? Feedback from users (who will be the most affected by this)
is very welcome. Please send replies to only one list (not both user and
dev).
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Simon Kitching <sk...@apache.org>.
On Fri, 2005-07-15 at 02:26 +0200, Torsten Curdt wrote:
> > Rob/Torsten, so what's the plan for this? Who's doing what etc?
> > Anything I can help make happen? Perms etc.
As noted in a separate email, an RC is up for review.
There is one question still to be decided though: do we *delete* the
existing 1.0 jar from ibiblio, or replace it with the right one.
I've argued for deleting it because otherwise projects that declare
dependencies on 1.0 will work differently when compiled on different
systems depending on what version (if any) is in the maven cache.
So person A can compile (getting the snapshot) and see a certain
behaviour. Person B can compile the same software on a different machine
(getting the correct 1.0) and see different behaviour. Very confusing.
I would rather see person B get an error message saying that
commons-cli-1.0.jar cannot be found on ibiblio. They will then go to the
cli website and see why, and fix the project to depend on 1.0.1 instead.
Ok, deleting the ambiguous 1.0.jar file doesn't completely solve the
problem for our hypothetical A and B if they both already have the jar
cached in maven's repo, but have different versions. Still, deleting
will warn as many people as possible of this issue.
Replacing the bad 1.0 with the good one at this point is probably not a
good idea either. Again, we have the issue where someone has a working
product based on the snapshot (under the illusion it is the real
release). By replacing this with the "real" 1.0 we could potentially
break their product if they depend on behaviour present in the snapshot
but not the real release. Instead, removing the bad 1.0 will alert them
to resolve the issue by hand.
Actually, we should probably continue to make the bad 1.0 available but
under a different name for the use of people who want to continue using
it. I'd be happy to go in and rename the jar right now, to something
like
commons-cli-1.0-snapshot.jar
if there is agreement on that.
The alternative is to leave the bad 1.0 there on the principle that
it hasn't actually broken anyone's code that we are aware of (just
confused a few people who spotted that it wasn't the real 1.0 release).
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
Comments? Feedback from users (who will be the most affected by this)
is very welcome. Please send replies to only one list (not both user and
dev).
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Fri, 2005-07-15 at 02:26 +0200, Torsten Curdt wrote:
<snip>
> On the other hand people might be busy hacking
> and chatting away in Stuttgart ;)
>
> ...anyone coming BTW?
i'll be arriving monday evening
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Torsten Curdt <tc...@vafer.org>.
> Rob/Torsten, so what's the plan for this? Who's doing what etc?
> Anything I can help make happen? Perms etc.
Well, I'm happy to help out with whatever I can do.
I can take care of the repository part e.g. ...but
I don't have access to do the actual release.
> Most importantly, what's our timeline on the various parts;
> jdiff/clirr, fixing etc?
I think it would be good to have it released by
the end of next week. IMHO we don't need any RCs.
Just build it and check the jdiff/clirr results.
On the other hand people might be busy hacking
and chatting away in Stuttgart ;)
...anyone coming BTW?
cheers
--
Torsten
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Henri Yandell <fl...@gmail.com>.
Rob/Torsten, so what's the plan for this? Who's doing what etc?
Anything I can help make happen? Perms etc.
Most importantly, what's our timeline on the various parts;
jdiff/clirr, fixing etc?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Tue, 2005-07-12 at 14:15 +0200, Torsten Curdt wrote:
<snip>
> >>>> What's left to do for the 1.0.1 release?
> >>>>
> >>>>
> >>> We need to copy the 1.0 tag and get it buildable again. The
> >>> changes to the common maven config have meant that this tag is
> >>> no longer buildable against the current setup and I haven't had
> >>> much luck getting a working copy into the correct historical
> >>> state to build using the old one.
> >>>
> >>>
> >> Hm... that's unfortunate. So we would not
> >> provide any version 1.0 but only the 1.0.1
> >> anymore?
not sure i parse this correctly...
AIUI there's a 1.0 distribution available in
http://www.apache.org/dist/jakarta/commons/cli/binaries/.
> ...maybe we should then make an
> >> announcement, provide the jdiff and be
> >> sure 1.0.1 can replace 1.0 without any
> >> hurdles.
> >> WDYT?
> >>
> >
> > I think the best plan for a 1.0.1 is simply to go from the 1.0 tag
> > with the necessary build changes (i.e. no code changes) as Simon
> > pointed out. It just needs a little work to get it there. I'm
> > sure a jdiff report can be produced to reassure people if needed.
> >
>
> Ok ...sounds cool.
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Torsten Curdt <tc...@apache.org>.
>> Same here ...what about a quick vote?
>>
>
> Could do. I'd like to see someone with the necessary perms and
> knowledge just get the correct jar in apache's maven repository,
> it sounds like that would get sync'd across to ibiblio.org
> automatically anyway. I think its just a case of copying the
> correct version into some directory on the daedalus but I'm not
> sure where and I don't think I have access anyway.
>
I can do that ...but I would us to agree
on that first.
>>>> What's left to do for the 1.0.1 release?
>>>>
>>>>
>>> We need to copy the 1.0 tag and get it buildable again. The
>>> changes to the common maven config have meant that this tag is
>>> no longer buildable against the current setup and I haven't had
>>> much luck getting a working copy into the correct historical
>>> state to build using the old one.
>>>
>>>
>> Hm... that's unfortunate. So we would not
>> provide any version 1.0 but only the 1.0.1
>> anymore? ...maybe we should then make an
>> announcement, provide the jdiff and be
>> sure 1.0.1 can replace 1.0 without any
>> hurdles.
>> WDYT?
>>
>
> I think the best plan for a 1.0.1 is simply to go from the 1.0 tag
> with the necessary build changes (i.e. no code changes) as Simon
> pointed out. It just needs a little work to get it there. I'm
> sure a jdiff report can be produced to reassure people if needed.
>
Ok ...sounds cool.
cheers
--
Torsten
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Rob Oxspring <ro...@imapmail.org>.
Torsten Curdt wrote:
>>>>
>>> Could we come up with a decision on that one?
>>> I think it's important to fix this.
>>> Replace or delete the bogus 1.0 jar?
>>>
>> Personally I think this should be done ASAP - at least its stops the
>> problem from be being spread further.
>>
>
> Same here ...what about a quick vote?
Could do. I'd like to see someone with the necessary perms and knowledge just
get the correct jar in apache's maven repository, it sounds like that would
get sync'd across to ibiblio.org automatically anyway. I think its just a
case of copying the correct version into some directory on the daedalus but
I'm not sure where and I don't think I have access anyway.
>
>>> What's left to do for the 1.0.1 release?
>>>
>> We need to copy the 1.0 tag and get it buildable again. The changes
>> to the common maven config have meant that this tag is no longer
>> buildable against the current setup and I haven't had much luck
>> getting a working copy into the correct historical state to build
>> using the old one.
>>
>
> Hm... that's unfortunate. So we would not
> provide any version 1.0 but only the 1.0.1
> anymore? ...maybe we should then make an
> announcement, provide the jdiff and be
> sure 1.0.1 can replace 1.0 without any
> hurdles.
>
> WDYT?
I think the best plan for a 1.0.1 is simply to go from the 1.0 tag with the
necessary build changes (i.e. no code changes) as Simon pointed out. It just
needs a little work to get it there. I'm sure a jdiff report can be produced
to reassure people if needed.
Rob
>
> cheers
> --
> Torsten
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Torsten Curdt <tc...@apache.org>.
>>>
>> Could we come up with a decision on that one?
>> I think it's important to fix this.
>> Replace or delete the bogus 1.0 jar?
>>
> Personally I think this should be done ASAP - at least its stops
> the problem from be being spread further.
>
Same here ...what about a quick vote?
>> What's left to do for the 1.0.1 release?
>>
> We need to copy the 1.0 tag and get it buildable again. The
> changes to the common maven config have meant that this tag is no
> longer buildable against the current setup and I haven't had much
> luck getting a working copy into the correct historical state to
> build using the old one.
>
Hm... that's unfortunate. So we would not
provide any version 1.0 but only the 1.0.1
anymore? ...maybe we should then make an
announcement, provide the jdiff and be
sure 1.0.1 can replace 1.0 without any
hurdles.
WDYT?
cheers
--
Torsten
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Rob Oxspring <ro...@imapmail.org>.
Torsten Curdt wrote:
>>> Replacing the bad 1.0 on ibiblio with the correct one will make things
>>> even more confusing I think. People who have already downloaded the 1.0
>>> will not get the update (including maven users where the bad jar is
>>> cached in ~/.maven/...).
>>>
>>>
>>
>> But then at least what we have advertised as cli 1.0 would be the
>> version that we released officially and new integrations with
>> dependencies on that *released* jar will be built correctly. We need
>> to acknowledge this problem on the web site, but getting the 1.0
>> version on ibiblio the same as the version on the mirrors seems better
>> to me than leaving things in the state where they are. Again, could
>> be I am not looking at this the right way.
>
>
> Could we come up with a decision on that one?
> I think it's important to fix this.
>
> Replace or delete the bogus 1.0 jar?
Personally I think this should be done ASAP - at least its stops the problem
from be being spread further.
> What's left to do for the 1.0.1 release?
We need to copy the 1.0 tag and get it buildable again. The changes to the
common maven config have meant that this tag is no longer buildable against
the current setup and I haven't had much luck getting a working copy into the
correct historical state to build using the old one.
>
> cheers
> --
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Torsten Curdt <tc...@apache.org>.
>> Replacing the bad 1.0 on ibiblio with the correct one will make
>> things
>> even more confusing I think. People who have already downloaded
>> the 1.0
>> will not get the update (including maven users where the bad jar is
>> cached in ~/.maven/...).
>>
>>
>
> But then at least what we have advertised as cli 1.0 would be the
> version that we released officially and new integrations with
> dependencies on that *released* jar will be built correctly. We need
> to acknowledge this problem on the web site, but getting the 1.0
> version on ibiblio the same as the version on the mirrors seems better
> to me than leaving things in the state where they are. Again, could
> be I am not looking at this the right way.
Could we come up with a decision on that one?
I think it's important to fix this.
Replace or delete the bogus 1.0 jar?
What's left to do for the 1.0.1 release?
cheers
--
Torsten
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Phil Steitz <ph...@gmail.com>.
On 7/6/05, Simon Kitching <sk...@apache.org> wrote:
> On Wed, 2005-07-06 at 20:36 -0700, Phil Steitz wrote:
> > I am not sure that I have understood the thread(s) above fully, but it
> > would seem to me that we need to immediately get the correct, signed,
> > voted, *released* 1.0 jar into *both* java-repository and ibibilo. My
> > guess would be that via a combination of pom and .properties config
> > errors, someone published a snapshot (still named 1.0) to
> > java/repository and this got replicated to ibiblio.
>
> Replacing the bad 1.0 on ibiblio with the correct one will make things
> even more confusing I think. People who have already downloaded the 1.0
> will not get the update (including maven users where the bad jar is
> cached in ~/.maven/...).
>
But then at least what we have advertised as cli 1.0 would be the
version that we released officially and new integrations with
dependencies on that *released* jar will be built correctly. We need
to acknowledge this problem on the web site, but getting the 1.0
version on ibiblio the same as the version on the mirrors seems better
to me than leaving things in the state where they are. Again, could
be I am not looking at this the right way.
> It should be possible to get a 1.0.1 out within 24 hours I think, and as
> this problem has been around for over a year that should be soon enough.
>
> And once 1.0.1 is out I am very keen to see 1.0 deleted completely, so
> people get errors that should cause them to check the cli website, see
> the problem info, and upgrade to 1.0.1.
Why force users of the original release to upgrade?
>
> Pushing out the "good" 1.0 now only to delete it after 1.0.1 is released
> within the next 24 hours doesn't seem terribly useful.
The value would be to get the unreleased jar out of circulation and to
replace it with the correct, released version.
>
>
> > It goes without saying that we also need to find a way to prevent this
> > from recurring, and also find out immediately if there are other
> > situations like this. Anyone interested in helping to find a solution
> > to this should subscribe to repository@ and discuss the general
> > problem there.
>
> I agree. And the problem could well be a result of someone running a
> maven task which pushed this out without them realising. Maven is very
> powerful but can be confusing (at least I find it so). So looking into
> whether there is something that can be done to avoid future mistakes
> would be good.
Agreed. I posted to repository@ and we'll see what ideas people have.
Another thing we can do is add some docs to the commons web site
explaining how the deployment properties work. I will start another
thread to discuss this under [docs]
Phil
>
> Regards,
>
> Simon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Simon Kitching <sk...@apache.org>.
On Wed, 2005-07-06 at 20:36 -0700, Phil Steitz wrote:
> I am not sure that I have understood the thread(s) above fully, but it
> would seem to me that we need to immediately get the correct, signed,
> voted, *released* 1.0 jar into *both* java-repository and ibibilo. My
> guess would be that via a combination of pom and .properties config
> errors, someone published a snapshot (still named 1.0) to
> java/repository and this got replicated to ibiblio.
Replacing the bad 1.0 on ibiblio with the correct one will make things
even more confusing I think. People who have already downloaded the 1.0
will not get the update (including maven users where the bad jar is
cached in ~/.maven/...).
It should be possible to get a 1.0.1 out within 24 hours I think, and as
this problem has been around for over a year that should be soon enough.
And once 1.0.1 is out I am very keen to see 1.0 deleted completely, so
people get errors that should cause them to check the cli website, see
the problem info, and upgrade to 1.0.1.
Pushing out the "good" 1.0 now only to delete it after 1.0.1 is released
within the next 24 hours doesn't seem terribly useful.
> It goes without saying that we also need to find a way to prevent this
> from recurring, and also find out immediately if there are other
> situations like this. Anyone interested in helping to find a solution
> to this should subscribe to repository@ and discuss the general
> problem there.
I agree. And the problem could well be a result of someone running a
maven task which pushed this out without them realising. Maven is very
powerful but can be confusing (at least I find it so). So looking into
whether there is something that can be done to avoid future mistakes
would be good.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Phil Steitz <ph...@gmail.com>.
I am not sure that I have understood the thread(s) above fully, but it
would seem to me that we need to immediately get the correct, signed,
voted, *released* 1.0 jar into *both* java-repository and ibibilo. My
guess would be that via a combination of pom and .properties config
errors, someone published a snapshot (still named 1.0) to
java/repository and this got replicated to ibiblio.
I am -1 on pushing out any sort of "emergency" release without proper
plan, review and vote. Has anyone run a clirr report on the bogus
and real release jar to see what the binary compability problems are
in both directions (users of the original jar could be breaking as we
speak, IIUC)? I know I may seem to be dicounting the problems of
clients using the "bogus" jar. I am not downplaying those problems
and feel that we need to acknowledge them on the web page and move
with all deliberate speed to develop a release of some kind that
matches the API in the bogus jar; but the official apache releases are
what we vote on and push out to the mirrors. I don't think it is a
good idea to circumvent or change release processes to correct
software distribution errors.
It goes without saying that we also need to find a way to prevent this
from recurring, and also find out immediately if there are other
situations like this. Anyone interested in helping to find a solution
to this should subscribe to repository@ and discuss the general
problem there.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by Torsten Curdt <tc...@apache.org>.
> there's a possibility that this won't work. someone might need to talk
> to the maven folks since i believe that ibiblio has non-deletion
> policies which may prevented this.
I just had a chat over at #maven at codehaus.org
...we could just update the jar in the apache
repo and it should be synch'd with ibiblio.
The apache repo is the definite source.
That should work.
> it's possible the bad jar got in there through the java repository
Actually that's most likely the reason why
> (http://www.apache.org/dist/java-repository/commons-cli/jars/ i think
> contains a different 1.0 jar to
> http://www.apache.org/dist/jakarta/commons/cli/binaries/.) should we ask
> the java repo team?
What would you like to ask?
Once the new release is out
the door I could update the
jar and put the new one up.
How does that sound?
> but +1 to actively pushing a fix out however it's done...
Yes, let's fix it
cheers
--
Torsten
Re: [CLI] two different versions of commons-cli-1.0.jar?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Wed, 2005-07-06 at 09:05 +0200, Torsten Curdt wrote:
> >>I could take care of pushing out the jar to
> >>ibilio ...but I think we should have a proper
> >>release or at least a tag for 1.0.1 then.
> >
> >
> > Sorry, I don't understand this.
>
> ibiblio# rm commons-cli-1.0.jar
> #scp commons-cli-1.0.jar minotaur
> #svn co https://.../CLI_1_0_1
> #maven jar
> #scp commons-cli-1.0.1.jar minotaur
>
> ...sync ...sync
>
> ibiblio# ls
> commons-cli-1.0.jar <-- the real 1.0!
> commons-cli-1.0.1.jar
>
> ;-)
there's a possibility that this won't work. someone might need to talk
to the maven folks since i believe that ibiblio has non-deletion
policies which may prevented this.
it's possible the bad jar got in there through the java repository
(http://www.apache.org/dist/java-repository/commons-cli/jars/ i think
contains a different 1.0 jar to
http://www.apache.org/dist/jakarta/commons/cli/binaries/.) should we ask
the java repo team?
but +1 to actively pushing a fix out however it's done...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org