3 ms·
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
by vharuck 3y ago
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 3y agoWhat 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.
- paulddraper 3y agotl;dr The author things that Flask should release a 2.* and have no breaking changes.
- barryrandall 3y agoThe 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.
- usrbinbash 3y ago> 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.