5 ms·

If every release has a single breaking change, then that language is said to be unstable/not-production ready. IMHO, that's not at all an acceptable way of doin

If every release has a single breaking change, then that language is said to be unstable/not-production ready. IMHO, that's not at all an acceptable way of doing point releases. People will just be scared of new releases. No one will adopt a new language version as soon as it releases. Java never breaks backwards compatibility and still there are people running Java 8. Imagine what would happen if every point release carries breaking changes. It makes you feel that the language is not mature, the library ecosystem broken, since you'll have to keep track of version compatibility for each library that you use. It's a nightmare for both library developers and end-users. Few people would like to use such a language

nuerow 5y ago
> If every release has a single breaking change, then that language is said to be unstable/not-production ready. IMHO, that's not at all an acceptable way of doing point releases. This. It makes absolutely no sense to claim that having to deal with a single non-backwards compatible release is somehow worse than having to deal with a sequence of non-backwards compatible releases. Even though the migration from Python2 to Python3 faced some resistence, if anything the decision was totally vindicated.
- burnished 5y ago
  I thought the use case mentioned made sense, that of essentially being able to perform patches in a series, as opposed to trying to fix many breaking changes at once. You know. Iterative development. I think 'makes absolutely no sense' is a little harsh.
ikerdanzel 5y ago
Python makes it to #1 over Java now. Python is breaking changes frequently. A lot of libraries need to be "tweak" to get it working even incremental changes within 3.x let along the big rift from 2 to 3. Although logically, few would like such language that breaks, current market for Python adoption buck this trend.

nuerow 5y ago

> If every release has a single breaking change, then that language is said to be unstable/not-production ready. IMHO, that's not at all an acceptable way of doing point releases. This. It makes absolutely no sense to claim that having to deal with a single non-backwards compatible release is somehow worse than having to deal with a sequence of non-backwards compatible releases. Even though the migration from Python2 to Python3 faced some resistence, if anything the decision was totally vindicated.

burnished 5y ago
I thought the use case mentioned made sense, that of essentially being able to perform patches in a series, as opposed to trying to fix many breaking changes at once. You know. Iterative development. I think 'makes absolutely no sense' is a little harsh.

ikerdanzel 5y ago

Python makes it to #1 over Java now. Python is breaking changes frequently. A lot of libraries need to be "tweak" to get it working even incremental changes within 3.x let along the big rift from 2 to 3. Although logically, few would like such language that breaks, current market for Python adoption buck this trend.