In article <[EMAIL PROTECTED]>, "Berin Loritsch"
<[EMAIL PROTECTED]> wrote:
>...
> What do you mean before compatibility is in place? Are you saying we
> cannot move anything until all our dependent projects notify us and tell
> us that they are ready?
>
> Can we handle a temporary incompatibility that lasts for a day--or at
> the most two?
The group voted on this change, it was done, and now there are some issues
with it. The answer is to move forward and fix the problems, rather than
always needing to go backwards.
In this case, Peter said "it broke compatibility". So the requirement is
to fix that, not necessarily to revert. Remember: a veto has a technical
reason behind it. The solution is to address the *reason* rather than to
simply revert changes. Thus, there would seem to be two solutions:
1) revert the changes to restore compat
2) come up with another mechanism to establish back-compat
(some kind of extra jar containing deprecated code(?) is what I think
Berin suggested; I'm obviously out of my element here :-)
Also, it is important to keep in mind that these are changes to CVS. It
would seem to be perfectly acceptable to allow incompatibilities to exist
within CVS for any period of time. For the *releases* ... yes, it does
seem to be extremely important to retain backwards compat (even if that
means whole swaths of deprecated classes/methods).
So... what are the constructive ways to move forward? What are the
choices?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
