commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Oxspring <roxspr...@imapmail.org>
Subject Re: [cli] VOTE: release 1.0.1
Date Wed, 06 Jul 2005 22:41:29 GMT
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: 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
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message