[pdonis]

> I'd say the respect towards the users is displayed by the frequency of breaking changes and the overall time to migrate, through deprecation warnings and at least security maintenance of older versions. Sometimes things need to change.

A change that brings new added value to users is a case where the change needs to be made, yes.

But the article's point is that the Flask changes don't seem to be doing that. They're not making breaking changes in order to introduce new features that add value for users. They're making breaking changes just because they feel like it, giving users no added value to compensate for the time and effort required to deal with the change. That's not respecting users.

[tetha]

I disagree with that, to be honest.

At a first glance, you might think "but where is the shiny carrot that makes me upgrade?" But the thing is - we have dealt with major upgrades at work which broke many things, added many features, changed things in undocumented ways, turned the whole dependency inside out.

That's a horrible experience. You end up running after ghosts: Is it the breaking change, is it a change due to a feature, what is even going on!

Looking at it, Flask 3 seems to be a simple batch of several breaking changes on the roadmap for quite some time. This is good - they thought about batching these breaking changes together to have one big bad one, opposed to like 6 of them over the 2 years. And you can upgrade, and you can clearly see if one of the breaking changes causes harm to your application, without having to worry about hundreds of other changes within the same major release.

[pdonis]

Batching a bunch of breaking changes together so they all come at once and you only have to deal with them once is fine.

What I am asking is, why did there even need to be a breaking change in the case of the function discussed in the article? No functionality changed; the Python standard library function was identical to the former Flask function. So why couldn't the Python standard library function have been imported into the Flask namespace to replace the former Flask function? Why force every user to do that manually?

[ilyt]

Throwing the crust away and refactoring stuff also "doesn't add new features" but it needs to be done to keep codebase good.

> giving users no added value to compensate for the time and effort required to deal with the change

... the users of free software. That didn't bother to find&replace one method in their plugin code.

[fiddlerwoaroof]

Refactoring is not a breaking change by definition: refactoring is preserving the same contract with a new implementation.

[ilyt]

I put "throwing the cruft away" in the same sentence EXPLICITLY to address that I am not just talking about refactoring.

Learn to read before throwing dictionary definitions at people

Providing method now-provided by standard libs is by definition unnecessary cruft. Nobody wants that in their codebase. They warned people for 2 years.

But apparently basic competence is too hard requirement in software ecosystems.

[pdonis]

> Providing method now-provided by standard libs is by definition unnecessary cruft. Nobody wants that in their codebase.

I don't think your sweeping claims here are justified. Importing the function from the standard library into the same namespace in your library where the function you previously implemented was is not "cruft". It's helping your users by not making a breaking change when you don't actually need to--no actual functionality changed.

> apparently basic competence is too hard requirement in software ecosystems

Your snark here is even less justified IMO than your sweeping claims above.