Comment by Sanddancer | Hacker News Reader

Comment by Sanddancer | Hacker News Reader

I think as a counterexample, one could look to projects like FreeBSD, which have had a long-running development branch and branches for release for a very long time. Breaking changes happen in -CURRENT, but within a stable branch -- 10.x, 11.x, etc, you even get things like ABI compatibility, so a module written for kernel 10.1 will work for kernel 10.2.

The example projects show more a lack of development discipline than a problem with the big break model. A version number change from 1.8.7 to 1.9.0 doesn't suggest big changes that one should be cautious of, causing problems. Linux Kernel 2.5 had the problem of a lack of developers willing to write more inclusive tests and a lack of a pre-determined roadmap. Python had the problem of a lack of a transition version where deprecation warnings were on by default. Successful breaks can be made when they are declared in advance so people can have reasonable feedback. The projects in question show communication problems, not problems with the idea.

> Python had the problem of a lack of a transition version where deprecation warnings were on by default.

I'm really not sure this is necessary, though perhaps I'm wrong. I expect that fewer people would have upgraded to 2.6 or 2.7 if they were full of warning printouts.

> Successful breaks can be made when they are declared in advance so people can have reasonable feedback

Python has an enormous amount of advance warning. Python3 was released at the same time as 2.6, which came with a warnings mode for breaking changes in python 3, then 2.7 allowed people to backport many of the newer features. There is an automated tool to do many of the conversions and you've been able to test your changes for the last seven years against a fully supported alternative, and 2.7 will be supported until 2020. That's a total of about 11 years from the launch of a working upgrade, it was being discussed a lot for at least a couple of years before the 3.0 launch and Guido says he first brought up the idea of py3k in 2000. I'm also sure you can write code that works in both 2 and 3, so there's even a fairly clear migration path.

If developers aren't going to change things given such a runway, would adding default deprecation warnings really make such a difference?

I'm sure I recall at the time that the transition was intended to take 10 years, and so is the problem simply that people are using a different measure of success than python did themselves?

>If developers aren't going to change things given such a runway, would adding default deprecation warnings really make such a difference?

I think many developers don't pay attention to these things. If it compiles - they've turned off the warnings - then it's fine. What's needed is the use of a "--use-deprecated-features" flag in order for the code to run/compile successfully. People pay attention when they need to change the build script in order to keep doing it wrong. Sure, they'll keep doing it wrong, but now they'll know it's serious.

But who is that targeting? Python programmers that haven't heard of python 3.X in the last 7 years?

Reply on news.ycombinator.com