6 ms·

https://semver.org/ https://semver.org/ Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API c

https://semver.org/ https://semver.org/ Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes So what exactly is the issue here?

fiddlerwoaroof 3y ago
The problem is that breaking changes in widely-used packages are disrespectful to your users. See Rich Hickey’s Spec-ulation
- bckr 3y ago
  Would it not work to specify the version when installing the packages?
  - seanc 3y ago
    Only to an extent. I can't think of a language environment where each package can have its own version of a dependency. Python certainly isn't one. So if you want any of the Flask 3.0 features you have to take the new Werkzeug, and see Flask-Login break.
    - fiddlerwoaroof 3y ago
      Node lets every package have its own versions of dependencies. But, imo, it’s better (less time spent fixing upgrade breakage/incentive to pick stable dependencies) in the long run to depend on latest and always update, fixing breakage as you go and only locking versions in CI so you can deploy a known bundle.
      - rgoulter 3y ago
        Of "Frequently update dependencies to latest" or "don't have to modify code which depends on others", you only get to pick one. If you're frequently updating to latest, you're on the bleeding edge; sometimes things will bleed more than others. If you're stable, you might not have the latest and greatest all the time. The attitude of expecting to always have the latest and greatest, but never have anything break, all while not paying for the effort, seems absurd to me.
        fiddlerwoaroof 3y ago
        It works pretty well, it’s like how continuous integration seemed absurd to people who spent months integrating changes and now is the standard practice. Anyways, in my experience, if you routinely use the latest and greatest versions of dependencies, over time you find that you stop using dependencies that make this painful. Anyways, I’m fine with accidental breakage. Deliberately choosing instability in the form of a major version release seems irresponsible for packages at the base of an entire ecosystem. (Absent some critical security issue that your users would have to address anyways as happened with log4j)
    - jasonpeacock 3y ago
      Rust (Cargo) supports this.
  - fiddlerwoaroof 3y ago
    No, because your users basically have to upgrade eventually, unless you commit to provide bug fixes (security especially) for every major version.
- tetha 3y ago
  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. Speaking of that, flask 2 was released in May 21. I can't really complain about some breaking changes every 2 years or so. That's almost like a linux distribution.
  - pdonis 3y ago
    > 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 3y ago
      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 3y ago
- croes 3y ago
  >But the Flask-Login team is not actively developing the extension anymore. So they should tie the development to an extension that isn't in further development?
  - fiddlerwoaroof 3y ago
    Breaking changes shouldn’t happen with the same name: if you want to break your users, pick a new name too
    - usrbinbash 3y ago
      The version number, and especially the major version, IS part of the name, so they did exactly that.
      - fiddlerwoaroof 3y ago
        Then require people to `import flask3` so you can install both major versions together.
        usrbinbash 3y ago
        No. That would break every single module that is compliant with flask 3.x and imports it with `import flask`. This simply isn't justified by the "benefit" of some old packages not having to change a single line of code. Yes, maybe in hindsight it would have been beneficial to put the major version of some packages (flask is far from the only one) directly into the package name, as a workaround for pythons inability to deal with multiple versions of the same module under the same name in one environment. But python works as it does, `import flask` is how god-knows how many projects use it, so that's how the show runs, period. If some package requires a certain version, it can pin that version in its `setup.py`. If a project requires a certain version it can pin that version in it's `requirements.txt`. If an environment requires a certain version, the admin can create a virtualenv.
        3y ago
- usrbinbash 3y ago
  > breaking changes in widely-used packages are disrespectful to your users No they are not. The flask team announces changes, deprecates things and uses major versions correctly. The major version change also doesn't happen frequently. If a package absolutely requires a certain version, IT CAN SPECIFY AS MUCH in its requirements. If it doesn't, tough luck.
skrebbel 3y ago
The issue is that releasing breaking changes sucks for your users. A numbering scheme doesn’t really make it suck any less.
- SteveNuts 3y ago
  Breaking changes are fine (and a lot of times completely necessary) as long as they are expected _for what you're trying to do_. The numbering scheme is meant to give predictability to breaking changes or backwards compatibility, so if followed correctly, it absolutely should make it suck less.
- usrbinbash 3y ago
  > A numbering scheme doesn’t really make it suck any less. Yes it does, because that "numbering scheme" tells my users when and if breaking changes happen. It also allows them to avoid them. Don't want to keep up with the dependency? Make the version a hard requirement. Done.
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 ago
  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.
- paulddraper 3y ago
  tl;dr The author things that Flask should release a 2.* and have no breaking changes.
- barryrandall 3y ago
  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.
- 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.
ilyt 3y ago
I think the author learned for first time of his life that framework plugins need to keep up with framework changes. 2 years (flask 2.0 release) should be plenty for deprecation notice.
- mixmastamyk 3y ago
  Breaking method was only deprecated six months according to the article.
toolslive 3y ago
in the context of python, what exactly is an api change? If my api is ``` def some_function(*args, **kwargs) -> JSON: ... ``` In essence, I'm pretty sure plenty of the changes in the set of parameters that are actually acceptable quite often changes accidentally (same for what's in the JSON)
regularfry 3y ago
Flask doesn't follow semver. This could just as easily have happened in 3.1.

https://semver.org/ https://semver.org/ Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes So what exactly is the issue here?

fiddlerwoaroof 3y ago

The problem is that breaking changes in widely-used packages are disrespectful to your users. See Rich Hickey’s Spec-ulation

bckr 3y ago
Would it not work to specify the version when installing the packages?
- seanc 3y ago
  Only to an extent. I can't think of a language environment where each package can have its own version of a dependency. Python certainly isn't one. So if you want any of the Flask 3.0 features you have to take the new Werkzeug, and see Flask-Login break.
  - fiddlerwoaroof 3y ago
    Node lets every package have its own versions of dependencies. But, imo, it’s better (less time spent fixing upgrade breakage/incentive to pick stable dependencies) in the long run to depend on latest and always update, fixing breakage as you go and only locking versions in CI so you can deploy a known bundle.
    - rgoulter 3y ago
      Of "Frequently update dependencies to latest" or "don't have to modify code which depends on others", you only get to pick one. If you're frequently updating to latest, you're on the bleeding edge; sometimes things will bleed more than others. If you're stable, you might not have the latest and greatest all the time. The attitude of expecting to always have the latest and greatest, but never have anything break, all while not paying for the effort, seems absurd to me.
      - fiddlerwoaroof 3y ago
        It works pretty well, it’s like how continuous integration seemed absurd to people who spent months integrating changes and now is the standard practice. Anyways, in my experience, if you routinely use the latest and greatest versions of dependencies, over time you find that you stop using dependencies that make this painful. Anyways, I’m fine with accidental breakage. Deliberately choosing instability in the form of a major version release seems irresponsible for packages at the base of an entire ecosystem. (Absent some critical security issue that your users would have to address anyways as happened with log4j)
  - jasonpeacock 3y ago
    Rust (Cargo) supports this.
- fiddlerwoaroof 3y ago
  No, because your users basically have to upgrade eventually, unless you commit to provide bug fixes (security especially) for every major version.
tetha 3y ago
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. Speaking of that, flask 2 was released in May 21. I can't really complain about some breaking changes every 2 years or so. That's almost like a linux distribution.
- pdonis 3y ago
  > 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 3y ago
    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 3y ago
croes 3y ago
>But the Flask-Login team is not actively developing the extension anymore. So they should tie the development to an extension that isn't in further development?
- fiddlerwoaroof 3y ago
  Breaking changes shouldn’t happen with the same name: if you want to break your users, pick a new name too
  - usrbinbash 3y ago
    The version number, and especially the major version, IS part of the name, so they did exactly that.
    - fiddlerwoaroof 3y ago
      Then require people to `import flask3` so you can install both major versions together.
      - usrbinbash 3y ago
        No. That would break every single module that is compliant with flask 3.x and imports it with `import flask`. This simply isn't justified by the "benefit" of some old packages not having to change a single line of code. Yes, maybe in hindsight it would have been beneficial to put the major version of some packages (flask is far from the only one) directly into the package name, as a workaround for pythons inability to deal with multiple versions of the same module under the same name in one environment. But python works as it does, `import flask` is how god-knows how many projects use it, so that's how the show runs, period. If some package requires a certain version, it can pin that version in its `setup.py`. If a project requires a certain version it can pin that version in it's `requirements.txt`. If an environment requires a certain version, the admin can create a virtualenv.
        3y ago
usrbinbash 3y ago
> breaking changes in widely-used packages are disrespectful to your users No they are not. The flask team announces changes, deprecates things and uses major versions correctly. The major version change also doesn't happen frequently. If a package absolutely requires a certain version, IT CAN SPECIFY AS MUCH in its requirements. If it doesn't, tough luck.

skrebbel 3y ago

The issue is that releasing breaking changes sucks for your users. A numbering scheme doesn’t really make it suck any less.

SteveNuts 3y ago
Breaking changes are fine (and a lot of times completely necessary) as long as they are expected _for what you're trying to do_. The numbering scheme is meant to give predictability to breaking changes or backwards compatibility, so if followed correctly, it absolutely should make it suck less.
usrbinbash 3y ago
> A numbering scheme doesn’t really make it suck any less. Yes it does, because that "numbering scheme" tells my users when and if breaking changes happen. It also allows them to avoid them. Don't want to keep up with the dependency? Make the version a hard requirement. Done.

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 ago
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.
paulddraper 3y ago
tl;dr The author things that Flask should release a 2.* and have no breaking changes.
barryrandall 3y ago
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.
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.

ilyt 3y ago

I think the author learned for first time of his life that framework plugins need to keep up with framework changes. 2 years (flask 2.0 release) should be plenty for deprecation notice.

mixmastamyk 3y ago
Breaking method was only deprecated six months according to the article.

toolslive 3y ago

in the context of python, what exactly is an api change? If my api is ``` def some_function(*args, **kwargs) -> JSON: ... ``` In essence, I'm pretty sure plenty of the changes in the set of parameters that are actually acceptable quite often changes accidentally (same for what's in the JSON)

regularfry 3y ago

Flask doesn't follow semver. This could just as easily have happened in 3.1.