[vharuck]

The post's point is that an API change is a very big deal, to be used only when the older version just can't work anymore or the newer version offers something much better. But the Flask team seems to have a much lower bar on what justifies the change. So the author feels unhappy he has to update a bunch of projects for no good reason.

[zbowling]

What stops folks from sticking with the last version of the last major point release? Do the flask folks not provide security or other update to older major point releases? Sometimes in the software lifecycle, you need to refactor and move on from older API designs. Even keeping old APIs around adds cruft, testable surface area you have to support, and slows down everything and adds risk with shipping software over time. Android, iOS, GTK, half the javascript and C++ libraries in the world, etc pop in into my head and all will break some amount in a major version update.

[usrbinbash]

> an API change is a very big deal, to be used only when the older version just can't work anymore

That's one opinion.

Another opinion is, that API and major version changes can be used whenever the maintainers of an open source project feel like it. No other reason is necessary. Because it's their project. They write the code. They don't have to justify that decision.

If a large portion of the projects userbase is unhappy about that, the project will lose traction and new project, or a fork, will arise.

[barryrandall]

The post would have a point if the Flask team treated this like a minor release (2.x -> 2.x+0.1) instead of a major (2.x -> 3.x) and hadn't issued a deprecation warning.

[paulddraper]

tl;dr The author things that Flask should release a 2.* and have no breaking changes.