commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <ggreg...@seagullsw.com>
Subject RE: [cli] v1 & v2 API compatibility
Date Mon, 08 Mar 2004 21:58:23 GMT
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. 

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

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.

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


Mime
View raw message