Should we be so strict on maintaining backwards compatibility?

[Tom Schindl]

Hi,

I agree in general but I'd like to mention once more that with Java-8
this problem is much smaller because you'd define version ranges on your
own product which have to match.

As I understood the new Java module system you can have multiple version
of e.g. JavaFX installed next to each other:
* javafx 2.2.0
* javafx 2.2.1

If you specify no upper bound you'll always the get the one with the
highest version beside that I agree that by JavaFX joining the OpenJDK
the project can't act as agile as it does at the moment with preview
builds, ... (we've all seen the first signs of this by "No zips download
for 2.2 even if the mac build has no JavaDoc attached") but I once more
hope that this will change a bit with the use of a java module system.

Tom

Am 15.05.12 02:05, schrieb 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
>>>
>>


-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                 geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834