commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory" <>
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"

It seems to me that a solution would be to delivery either: [cli] which

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

> -----Original Message-----
> From: news [] On Behalf Of
> Sent: Monday, March 08, 2004 13:00
> To:
> 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
> > reason to do so.
> >
> > Therefore, I propose to branch the v1 code and put it into
> > 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
> > to a vote.  I assume a decision of this nature requires a vote as it
> > almost like proposing a new subproject.
> >
> > This would also allow us to keep the org.apache.commons.cli package
> > both versions.
> >
> > Comments?
> I don't know how many people use CLI v1, but this kind of action can
> a
> huge ripple effect.
> IMO making backward incompatible changes should be deprecated :-), if
> 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
> to
> change code anyway - this just add a bit more inconvenience, but at
> avoid the "upgrade everything or nothing because one small library
> change".
> Costin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message