commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Keyes <j...@integralsource.com>
Subject Re: [cli] v1 & v2 API compatibility
Date Mon, 08 Mar 2004 14:39:07 GMT
> Rob Oxspring wrote:
>
>> John Keyes wrote:
>>
>> I spent today looking at realizing the v1 API with the v2 runtime. 
>> After making some progress, I started to wonder was there any 
>> compeling reason to do so.
>
> Nothing compelling - just ease of adoption.  Still haven't looked into 
> it in detail but an alternative to reimplementing the v1 api would be 
> to simply deprecate the package and provide an adapter or two - that 
> way people could perform the upgrade more gentley:
>
>   gBuilder.withOption(Cli1Adapter.adaptOption(cli1Option));
>
> or
>
>   parser.setGroup(Cli1Adapter.adaptOptions(cli1Options));
>   parser.parse(args);
>
> Not sure its worth the effort though - we don't want to support the 
> old codebase longer than necessary.

+1 - we need to keep the maintenance to a minimum

>> Therefore, I propose to branch the v1 code and put it into 
>> maintanence mode.  This will allow us to merge the v2 branch to the 
>> mainline (assuming it gets approval). I don't see this as being much 
>> of an overhead but I would like to hear what others think before 
>> putting this to a vote.  I assume a decision of this nature requires 
>> a vote as it is almost like proposing a new subproject.
>
> The overhead seems perfectly reasonable for a new major version - most 
> people accept api breakages for major versions anyway.

In the majority of cases people seem okay.  Just wouldn't like to step 
on anyones toes.

>> This would also allow us to keep the org.apache.commons.cli package 
>> for both versions.
>> Comments?
>
> We should probably queue up a review of the copyright statements in 
> the licence header if we merge back to the old package - I'm pretty 
> sure the rewrite versions all have 2003-2004 or 2004 but merging back 
> might mean that some of them should probably classed as edits of older 
> documents (hence start with older dates).  Dunno though - IANAL etc 
> etc.

Well we should deprecate all of the code there anyway.  Not sure what 
the best way to publicize this though.  Do we make a release of 1.1 
which has these changes for deprecation included?  To make this release 
we need to have the code licensed with AL2.

-John K


---------------------------------------------------------------------
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