Hi,
I just had a go at building from the 1.0 tag and realised that it still
relies on the old commons/build system and uses Apache License 1.1.
I've spent this evening merging changes from the trunk to the 1.x
branch, including both changes that bring it in line with the current
build system and licence requirements AND bugfixes applied to the 1.0
code. I've lined this up as the commons-cli-1.1:
http://people.apache.org/~roxspring/cli/distributions/
Alternatively we should be able to build a 1.0.1 as described below by
reverting to the old build system releasing under the old licence, but
I'm not sure if that is desirable.
Thoughts?
Rob
Rob Oxspring wrote:
Simon Kitching wrote:
Hi,
As noted here, there is a bad commons-cli-1.0.jar file in circulation.
It would appear that a trunk build somehow got uploaded to ibiblio as
"commons-cli-1.0.jar", ie every Maven user whose project depends on
commons-cli 1.0 is actually compiling against a snapshot of unknown
date.
http://marc.theaimsgroup.com/?l=jakarta-commons-user&m=112059979308549&w=2
This is badness indeed.
I propose that we cut a 1.0.1 release immediately which is simply a copy
of the 1.0 tag but with:
* version# updated to 1.0.1
* a note on the welcome page for the website noting the issue
We can then delete the commons-logging-1.0.jar from ibiblio. Note that
this will break every build in existence which depends on
commons-cli-1.0. However I think that's necessary: currently they
*think* they are compiling against 1.0 but are actually compiling
against a trunk snapshot from about 12 months after 1.0 was actually
released. Breaking the builds so people can fix their dependency is
probably the best option. Actually, if people have the jar in their
maven repository their build will probably still work - only new users
will break (which is probably a bad thing).
I'm willing to be release manager for this. Of course it would be better
if a CLI maintainer popped up to do this - Rob are you out there?
Here. Am happy to be release manager though haven't actually done it
before.
Torsten has indicated that there are some other bugfixes around and that
it might be time to release a version with actual changes.
Having just had a quick look, the CLI_1_BRANCH currently contains
identical contents to the CLI_1_0 tag and while trunk has some bugfixes
in it, it also has the 2.0 package. So I don't see an easy way to
quickly release 1.0+fixes as 1.0.1.
> I would
prefer to avoid that, though: releasing 1.0.1 with no changes can be
done right now with minimal effort.
Comments/votes?
[X] yes, release 1.0.1 and delete 1.0
[ ] let's wait for a CLI maintainer to do this
[ ] no, because.....
(Though am happy to be that CLI maintainer)
Rob
Regards,
Simon
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
