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:[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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
