[joseph]

I've had Python code break a number of times when moving between 3.x minor releases. For a distro like CoreOS that is single purpose and intentionally kept minimal, I can see the value in a rolling release. For a traditional OS though, I do not want to be forced to spend my day fixing stuff because an update ran last night. Choosing when to change language and dependency versions is a feature.

[mixmastamyk]

Python made a deliberate choice to do that, thankfully not too common.

[joseph]

How often is common to you? I've seen it happen plenty, and not just with Python. Even Go, which has a reputation for maintaining backwards compatibility, had bugs that caused breakage on patch releases during the go.mod transition. Even if breakage happens rarely, when it does happen it causes unplanned work. I'd rather be deliberate in when I choose to upgrade so I can plan for issues.

[mixmastamyk]

As mentioned, they weren't bugs but multiple planned breakages.

IMHO, Python devs learned the wrong lesson from the 2 --> 3 transition. Should have been, "minimize big breaks." Instead they learned, "make lots of small breaks spread out evenly and avoid X.0 releases." The result is that planning around deprecation (always be breaking) is untenable for enterprise-style development.