3 ms·

I love how they are ready to change behavior of existing code and require opting into a compat mode. I wish this way of fixing things properly while having opt-

I love how they are ready to change behavior of existing code and require opting into a compat mode. I wish this way of fixing things properly while having opt-in compat was more common. Too often we see aversion towards breaking changes for no obvious reason. If you don’t want things to break then don’t upgrade things.

redbar0n 5y ago
An upgrade shouldn’t be a downgrade. But too often it is. It breaks expectations and ruins trust. Soon, users learn, and in response turn off all upgrades by default. Success? If an upgrade breaks things then it should be made exceedingly explicit (not only in text, but in a dialog button) that you accept that your existing stuff will break, and you should be provided with measures and (at least description of) steps to overcome it.
exabrial 5y ago
Agree. Java also has a great history of providing off-ramps for legacy code. When JDK modules came out, they allowed disabling of the system. This served an important purpose to allow older codebases to upgrade to newer JDK versions that had important security fixes while buying timing for those apps to age out of existence. Always a pleasure working with the jdk.
Beltalowda 5y ago
I have a lot of little programs that are more or less finished: "does what it needs to do and there are no bugs". Some are public, some are not. I wrote them once – sometimes years ago – and they still work fine today. I really like it that code I write today still works in five or ten years without mucking about to "keep up to date". "Don't upgrade things" isn't as easy as you say: how do you get an old version of Ruby? How do you get an old browser? Do you even want that? Opt-in should be easy and painless, probably even the default for new projects (through some build file or whatnot; I'm not very familiar with Java), but I think making existing projects work has a lot of value.

redbar0n 5y ago

An upgrade shouldn’t be a downgrade. But too often it is. It breaks expectations and ruins trust. Soon, users learn, and in response turn off all upgrades by default. Success? If an upgrade breaks things then it should be made exceedingly explicit (not only in text, but in a dialog button) that you accept that your existing stuff will break, and you should be provided with measures and (at least description of) steps to overcome it.

exabrial 5y ago

Agree. Java also has a great history of providing off-ramps for legacy code. When JDK modules came out, they allowed disabling of the system. This served an important purpose to allow older codebases to upgrade to newer JDK versions that had important security fixes while buying timing for those apps to age out of existence. Always a pleasure working with the jdk.

Beltalowda 5y ago

I have a lot of little programs that are more or less finished: "does what it needs to do and there are no bugs". Some are public, some are not. I wrote them once – sometimes years ago – and they still work fine today. I really like it that code I write today still works in five or ten years without mucking about to "keep up to date". "Don't upgrade things" isn't as easy as you say: how do you get an old version of Ruby? How do you get an old browser? Do you even want that? Opt-in should be easy and painless, probably even the default for new projects (through some build file or whatnot; I'm not very familiar with Java), but I think making existing projects work has a lot of value.