Posted by
Paul Johnston on
Dec 15, 2009; 4:56am
URL: http://imagej.273.s1.nabble.com/ImageJ-development-involvement-contributions-tp3690030p3690039.html
I agree with Raymond, people should not resist or fear change. To
demand 100% backwards compatibility forever ultimately would doom any
software project, because it assumes that all potential problems were
conceived and accounted for at the initial design. Furthermore it
assumes that the world outside the system never changes either, which
is of course false. Just as fire is a natural part of a forest
ecosystem, refactoring and redesign is a normal part of software
development. Plus, if people are using specific plugins that are no
longer being developed, there is no need to upgrade the core imagej
for that use case.
But all this talk doesn't really matter anyway, because its the code
that speaks for itself, and the number of downloads/interest that
decides. So people should spend more time just doing what they are
good at and not worry so much about the outcome, like it or not, it
will decide itself.
For me, each experiment that I do which has a dependency on imagej
gets the core and required plugin set placed in source control
alongside my imaging data. That way I always know that I can go back
and be able to repeat the analysis without worrying about other things
changing.
Paul
On Mon, Dec 14, 2009 at 12:50 PM, Raymond Martin <
[hidden email]> wrote:
> Hi David,
>
>> So, why can't we have 100% backward compatibility?
>>
>> Are changes that would preclude this really all that necessary?
>
> The reason is that it is impossible to know how to make something 100%
> backwards compatible without doing experiments first. Nobody knows exactly
> what the functionality is yet, therefore there is no way to determine if full
> backwards compatibility is possible.
>
> Moving forward in software is a process of discovery, plus in another few
> years, 5 or 10 maybe, reinvention of at least some parts of the program will
> have to be done again because that is the nature of computer science/software
> engineering, domains that are still very much in their infancy. It is just
> going to keep moving and changing. And users are going to want newer,
> better functionality due to the needs of the domains they are applying the
> application to.
>
> So it is really about how the need for change is handled and not about whether
> it is needed.
>
> Raymond
>