Should we be so strict on maintaining backwards compatibility?

[Tom Eugelink]

Kirill asked that same question a long time ago for his Substance library and it is a very valid one. Like then I would vote to maintain backwards compatibility in all minor release, but allow for well considered breaking on major releases (I have a candidate already BTW ;-). This would also prevent the stacking over all releases; design decisions from Java 1.0 are still plaguing 7.0.

Tom


On 2012-05-14 19:46, Pedro Duque Vieira wrote:
> Hi,
>
> I wanted to raise a question: "should we be so strict on maintaining
> backwards compatibility?".
> I'm seeing on this mailing list that maintaining backwards compatibility is
> of utmost importance for Oracle.
>
> The problem with maintaining backwards compatibility is that errors/bad
> decisions done on the past, will remain in the future. And the more
> releases are put out the bigger the problem with past mistakes will be.
> Can't we compensate for introducing backwards incompatibility by releasing
> detailed guides on migrating? Or even introducing automatic scripts for
> migration (maybe even on netbeans releases)?
>
> I prefer the pain of migrating code to the pain of having past mistakes
> present forever. I will be much happier if I know that all the design
> decisions present on JavaFX are the best possible to date.
>
> Forgive me if this is a dumb question, I just wanted to raise the issue.
> I'm really not fully aware of the costs vs gains on this.
>
> Thanks, best regards,
> --
> Pedro Duque Vieira