Should we be so strict on maintaining backwards compatibility?
tbee at tbee.org
Mon May 14 11:29:51 PDT 2012
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.
On 2012-05-14 19:46, Pedro Duque Vieira wrote:
> 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
More information about the openjfx-dev