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:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Monday, March 08, 2004 13:00 > To: [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
