Should we be so strict on maintaining backwards compatibility?

[Daniel Zwolenski]

With auto-updates then we have absolutely no choice in the matter. We must
be 100% backwards compatible at all times otherwise a perfectly functioning
system one day is cactus the next without anyone doing anything. I would
argue this goes down to look and feel too - things like mouse click dismiss
behaviour, fixes to css styling, etc. Nothing must ever break.

If we had a deployment solution that allowed developers to pin their code
to a certain Java/JFX version then I agree with the idea that minor version
changes should be backwards compatible, whereas major versions can have an
upgrade path. Allows for improvements over time, instead of Swing's keep it
stuck in the 80's until it is so dated it has to be killed and replaced.

Another (even better) alternative is a (not so popular) one I've raised
earlier: decouple JFX from the JRE into a normal Java library that gets
added-on. Maybe the core native window/rendering stuff (prism or glass or
whatever the root building blocks are) should be part of the JRE (and so
always are backwards compatible), but all the Control, CSS, Animation,
Chart, etc stuff could/should all be libraries in my opinion. Still
published by Oracle, still owned/worked on by the same teams - just
packaged separately, and so allowing a separate release/version path and
pace. Backwards compatibility issues get reduced to the normal challenges
in this area and releases can happen at times that make sense to the JFX
team, not dictated by the slower, more cumbersome JRE process.



On Tue, May 15, 2012 at 6:02 AM, Slavko Scekic <scekics at gmail.com> wrote:

> And what do you think, what changes would be worth breaking the backwards
> compatibility for?
>
> On Mon, May 14, 2012 at 9:22 PM, Pedro Duque Vieira <
> pedro.duquevieira at gmail.com> wrote:
>
> > Yes, that's true. Kirill was a proponent of breaking backwards
> > compatibility. I used his libraries a lot: flamingo, substance, etc and
> for
> > each release I had to do some migration.
> > My experience with Kirill's libraries tells me that breaking backwards
> > compatibility is worse it. Having wrong decisions plaguing the next
> > releases is far worse. It was a bit of a pain to migrate, but one worse
> > enduring.
> >
> > I think changes should be made as quickly as possible if we wait till the
> > next major release, the migration step will be worse, and the
> errors/wrong
> > decisions will accumulate into a worse problem each release.
> >
> >
> > 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
> >
> > --
> > Pedro Duque Vieira
> >
>