On Sun, 2005-07-17 at 19:31 +0200, Mattias Jiderhamn wrote:
> Stephen Colebourne wrote:
> >Simon Kitching wrote:
> >>I am aware that a number of people have expressed doubt about whether
> >>there should *be* a 1.0.1 release while others have backed it. This vote
> >>is an opportunity to see which approach people want to go with.
> >...
> >My preferred option is to just fix the repository, replacing bad 1.0
> >with good 1.0, and add a comment to the website.
> >
> >If there is an insistance on a uniquely named jar then my preferred
> >option is to copy 1.0 to 1.0b _without_any_changes_whatsoever_.
>
> Although not a commiter I agree with the above, but if 1.0b is
> released, I think there should be one tiny change: the reason for the
> release should be added to the release notes. I hate when there is a
> "new" release, and you can't find any information about the changes -
> or if there are any.
====
Stephen:
How do you plan to update the CLI website without a new release? As svn
tags are actually branches I guess it's possible to modify the
xdocs/index.xml file within tags/CLI_1_0 though that's not entirely
elegant.
Note also that the commons-build setup has moved on so that the CLI
website can't be built against the current commons-build. I guess it's
possible to get the commons-build that was current at the time CLI was
released (Nov 2002) and use that to generate the website. However this
means the generated site will still be referring to CVS and contain a
number of other obsolete pieces of information.
====
Matthias:
Stephen isn't suggesting a release. He's suggesting simply going into
the dir that is replicated to ibiblio and doing:
cp the-real-jar commons-cli-1.0.jar
Once ibiblio has replicated, any maven user without commons-cli-1.0.jar
already cached on their machine will get the "real" 1.0 jar. Maven users
with the "bad" 1.0.jar file already cached on their machine will end up
still using that bad jar without any notifications.
I'm not quite sure what the bit about "1.0b" means - whether Stephen is
suggesting
mv commons-cli-1.0.jar commons-cli-1.0b.jar # save the bad one
cp ${real-1.0-jar} commons-cli-1.0.jar # replace the good one
or
cp ${real-1.0-jar} commons-cli-1.0b.jar
I hope it's not the latter, as people who download the 1.0 distribution
bundle from apache or its mirrors will get a file named
commons-cli-1.0.jar; I don't think it would be nice for this file to
match the 1.0b jar but not the 1.0 jar from ibiblio.
And we certainly can't update the RELEASE-NOTES.txt file without a new
release.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
