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 Tue, 09 Mar 2004 00:00:12 GMT
Gary Gregory wrote:

> Sorry to be jumping late in the discussion but since I am a Cli "1"
> user...
> 
> It seems to me that a solution would be to delivery either: [cli] which
> is 
> 
> (1) cli2 and cli1 is still available on the site OR 
> (2) "cli1.jar"+"cli2.jar" where cli1 is just as it is now, NOT
> re-implemented on top of cli2. This allows for 0 risk of subtle
> behavioral changes and 100% backwards compatibility. 

Not too sure what the difference is between these choices.

> I assume that both versions are in completely separate packages. Make
> both versions downloadable from the site. Here is why. I favor (1).

This is what I proposed (but using a branch for the cli1 code and using 
the mainline for the cli2 code).

> > I am cli1 user; I can keep on using cli1 as is. I want to use cli2 with
> new code. I can migrate from cli1 to cli2 at my leisure. Then I can get
> rid of cli1.jar (or whatever it is called) for good.

Absolutely.  We want to minimize the effect on users.  This is why I 
raised the topic in the first place.  Thanks for the direction.

-John K

> My 2c,
> Gary
> 
> 
>>-----Original Message-----
>>From: news [mailto:news@sea.gmane.org] On Behalf Of
> 
> cmanolache@yahoo.com
> 
>>Sent: Monday, March 08, 2004 13:00
>>To: commons-dev@jakarta.apache.org
>>Subject: Re: [cli] v1 & v2 API compatibility
>>
>>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.
>>>
>>>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.
>>>
>>>This would also allow us to keep the org.apache.commons.cli package
> 
> for
> 
>>>both versions.
>>>
>>>Comments?
>>
>>I don't know how many people use CLI v1, but this kind of action can
> 
> have
> 
>>a
>>huge ripple effect.
>>
>>IMO making backward incompatible changes should be deprecated :-), if
> 
> the
> 
>>API can't be maintained you should use a different package name ( like
>>cli2 ), to allow people to keep using both versions at the same time.
>>
>>Since the apis are incompatible and users who chose to upgrade will
> 
> have
> 
>>to
>>change code anyway - this just add a bit more inconvenience, but at
> 
> least
> 
>>avoid the "upgrade everything or nothing because one small library
>>change".
>>
>>Costin
>>
>>
>>---------------------------------------------------------------------
>>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