Backwards compatibility

[ctrueden]

Hi everyone,

There has recently been a lot of discussion surrounding the idea of a new
version of ImageJ having "near 100% backwards compatibility" with the
current version. Some have argued that 100% compatibility is necessary and
achievable, while others have claimed that such a goal is unrealistic.

I have posted a very brief explanation to imagejdev.org (
http://imagejdev.org/plan) regarding how we will maintain backward
compatibility while simultaneously rearchitecting the project into various
modular components. In short, the plan is to maintain the existing ij.* API
as completely as possible, but as a compatibility layer into an updated
package tree (perhaps imagej.* or ijx.*).

We have also posted a proof-of-concept version of the IjX refactoring (
http://imagejdev.org/files/imagej/ImageJX_Mar09.pdf) at:
http://imagejdev.org/source-code

Currently, the IjX approach does not maintain 100% compatibility—as Grant
has stated, you must make some minor changes to plugins and recompile them.
We realize this situation is highly undesirable, and are committed to
producing a framework in which existing plugins continue to function without
modification. LOCI is still in the process of bringing new developers on
board, but in January we will thoroughly examine the source code, and I am
optimistic we will be able to find a solution to the compatibility problem.

To minimize regression bugs as development continues, we will create an
extensive suite of unit tests which run automatically at regular intervals.
As part of these tests, we will include tests for a substantial number of
existing plugins (both core and third party). As new plugins become part of
popular workflows, they become increasingly critical, and can be added to
the ImageJDev test suite.

-Curtis

[was: ImageJ development involvement/contributions]
On Mon, Dec 14, 2009 at 1:41 PM, David Webster <[hidden email]>wrote:

> So, why can't we have 100% backward compatibility?
>
> Are changes that would preclude this really all that necessary?
>

[was: Laseray, contributions, ImageJ]
On Mon, Dec 14, 2009 at 3:33 PM, Jim Quinn
<[hidden email]>wrote:

> As a lurker and enduser for many years, I would like
> to see very high (99%+) backward compatibility.
>
> Evolution, not revolution, is what got NIHImage and ImageJ
> to the high utility that it enjoys today.
>

[was: API vs. Scripting?]
On Wed, Oct 7, 2009 at 10:58 AM, Wilhelm Burger <[hidden email]> wrote:

> 2) Maintaining backward compatibility and keeping the IJ community on
> board has been a central issue in this list from the beginning. But
> assuming the API is not so important, would it be conceivable to write
> a radically new API together with a scripting layer that emulates IJ's
> existing functionality? I.e, to keep the crowd happy while at the same
> time providing a clean foundation for further development?
>

[was: Outsider's opinion]
2009/10/22 Gábor Bakos <[hidden email]>

> Have you considered a compatibility layer to 1.x ImageJ? It would give you
> design freedom for the new version, and would be a good test about the
> flexibility of the new design whether it is flexible enough or not. (I have
> to admit it is also possible that this is impossible, I have not tried to do
> it.)
>

[was: ImageJ development involvement/contributions]
On Tue, Dec 15, 2009 at 12:09 PM, Adrian Daerr <
[hidden email]> wrote:

> On 15/12/09 5:56, Paul Johnston wrote:
> > I agree with Raymond, people should not resist or fear change.  To
> > demand 100% backwards compatibility forever ultimately would doom any
> > software project
>
> I agree as well. This list is one of the strongest arguments that
> experiments need not be feared, even if a couple of plug-ins break: I
> have always been impressed with the extremely fast reaction to bug
> reports (including from Wayne of course, but not only!). So I believe
> that if a few percent of currently used plug-ins stop working due to a
> deep design change and despite a backward compatibility layer, and those
> plug-ins are not updated by their original authors spontaneously,
> chances are high that a post on this mailing list will solve the problem
> within hours. So in my opinion, instead of "100% backwards
> compatibility", a new design should "simply" (quotes because it'll be
> hard enough to do even then) strive at providing a compatibility for
> most plug-ins and such that the broken ones can be fixed by as little
> changes as possible. I am optimistic that this list will take care of
> users with no programming knowledge as it has in the past.
>