6 ms·

> We don’t aim to make a big feature release of Polars 2.0. In fact we hope it to be a boring experience for you. The reason we bump this major version is that

> We don’t aim to make a big feature release of Polars 2.0. In fact we hope it to be a boring experience for you. The reason we bump this major version is that we can get rid of design decisions made in the past that currently block us and then we want to change defaults to more sensible settings that will benefit a greater audience I know this take reveals me as a very dull person, but I love seeing projects take semver seriously like this! Version bumps should really be about removing deprecated cruft rather than shiny new features. I've used polars for a while now, and their focus on stability was a big part if convincing me to make the jump initially!

Bluestein 16d ago
"Tranquil development" (vs. "hype-driven shipping") :)
dist-epoch 16d ago
That being said Polars is one of the few Python libraries from the hundreds I use that I need to read the notes of every minor release (eg 1.44 -> 1.45), because they tend to frequently deprecate, remove or change features.
- duskdozer 16d ago
  It sounds like they should be on a version much higher than 2.x then.
  - sanderjd 15d ago
    Deprecating without breaking is fine in a minor version under semver.
    - tialaramex 15d ago
      There's also always a "strictness" curve. Rust has specific rules where you could write something which doesn't break those rules but does break people who've done something very specific At some point you reach the Hyrum's Law / Spacebar Heating edge where sure, there's no reasonable technical definition which concludes your change "broke" people but somebody's solution used to work and now it doesn't and they're angry about that. To give an example that's only slightly less ridiculous than spacebar heating, maybe somebody depended on being able to parse a file from your library, you re-designed the library, there are no API changes but they're parsing your source code and now their approach doesn't work. Generally, libraries with fewer and lighter users tend to be more lax, maybe they forgot to make a structure opaque, that's a break but none of their users notice, or they forgot to make an error type non-exhaustive, but everybody using their type had a default clause so no harm done when they add a new value. Hyrum means that as you get bigger and more important, some day, the spacebar heating problem happens and too bad. A language (like Rust) can help you forestall that day somewhat, and reduce the blast radius when it does, but it is inevitable, Hyrum's law wasn't something you can outright prevent from happening, it's a factor for engineers to consider when designing systems, like misuse resistance.
      - sanderjd 15d ago
        Yeah. Agreed.
    - 0x457 15d ago
      Did you miss "remove or change features." ?
      - sanderjd 15d ago
        No, I was just making a narrower point about one aspect of the comment.
- esafak 15d ago
  A library is a collection of features, and any of them could have breaking changes. That's why semver is insufficient. It would be good to have a standardized way to indicate breaking changes in components, like changesets.
nicce 16d ago
> Version bumps should really be about removing deprecated cruft rather than shiny new features. Can there be deprecated cruft without new features? :-D
- kvdveer 16d ago
  Ideally: no. All new shiny new features shouldn't have waited for the (N+1).0 version, they should already have been part of the (N).(M) version. In practice, the removing the deprecated cruft will remove blockers for some new features, but that should be rare.
- SkiFire13 16d ago
  Yes, the features don't need to be added immediately.
- illiac786 15d ago
  Good question. I guess sometimes stuff becomes unnecessary due to external factors and not due to new features.
altern8 16d ago
Aren't major versions supposed to indicate breaking changes..? That's how I thought semantic versioning worked
- theptip 15d ago
  Concretely, TFA lists a bunch of input validation that is being made more strict in the default configuration.
- suddenlybananas 16d ago
  >The reason we bump this major version is that we can get rid of design decisions made in the past that currently block us and then we want to change defaults to more sensible settings that will benefit a greater audience I don't know how to read this sentence other than "there are breaking changes we want to make"
  - altern8 15d ago
    I see. Just making sure I had it right :-)
    - winniewinnie 15d ago
      [flagged]
  - magicmicah85 15d ago
    The migration guide does say there are breaking changes, but the interpretation I have is "this won't have new features but allows us to develop new features".
- cassianoleal 15d ago
  Not every product uses SemVer
  - winniewinnie 15d ago
    But Polars does: https://docs.pola.rs/development/versioning/ https://docs.pola.rs/development/versioning/ > Polars adheres to the semantic versioning specification: And it does have breaking changes in 2.0. The original asker presumably missed that. E: On the other hand, that whole page on versioning seems inconsistent.

Bluestein 16d ago

"Tranquil development" (vs. "hype-driven shipping") :)

dist-epoch 16d ago

That being said Polars is one of the few Python libraries from the hundreds I use that I need to read the notes of every minor release (eg 1.44 -> 1.45), because they tend to frequently deprecate, remove or change features.

duskdozer 16d ago
It sounds like they should be on a version much higher than 2.x then.
- sanderjd 15d ago
  Deprecating without breaking is fine in a minor version under semver.
  - tialaramex 15d ago
    There's also always a "strictness" curve. Rust has specific rules where you could write something which doesn't break those rules but does break people who've done something very specific At some point you reach the Hyrum's Law / Spacebar Heating edge where sure, there's no reasonable technical definition which concludes your change "broke" people but somebody's solution used to work and now it doesn't and they're angry about that. To give an example that's only slightly less ridiculous than spacebar heating, maybe somebody depended on being able to parse a file from your library, you re-designed the library, there are no API changes but they're parsing your source code and now their approach doesn't work. Generally, libraries with fewer and lighter users tend to be more lax, maybe they forgot to make a structure opaque, that's a break but none of their users notice, or they forgot to make an error type non-exhaustive, but everybody using their type had a default clause so no harm done when they add a new value. Hyrum means that as you get bigger and more important, some day, the spacebar heating problem happens and too bad. A language (like Rust) can help you forestall that day somewhat, and reduce the blast radius when it does, but it is inevitable, Hyrum's law wasn't something you can outright prevent from happening, it's a factor for engineers to consider when designing systems, like misuse resistance.
    - sanderjd 15d ago
      Yeah. Agreed.
  - 0x457 15d ago
    Did you miss "remove or change features." ?
    - sanderjd 15d ago
      No, I was just making a narrower point about one aspect of the comment.
esafak 15d ago
A library is a collection of features, and any of them could have breaking changes. That's why semver is insufficient. It would be good to have a standardized way to indicate breaking changes in components, like changesets.

nicce 16d ago

> Version bumps should really be about removing deprecated cruft rather than shiny new features. Can there be deprecated cruft without new features? :-D

kvdveer 16d ago
Ideally: no. All new shiny new features shouldn't have waited for the (N+1).0 version, they should already have been part of the (N).(M) version. In practice, the removing the deprecated cruft will remove blockers for some new features, but that should be rare.
SkiFire13 16d ago
Yes, the features don't need to be added immediately.
illiac786 15d ago
Good question. I guess sometimes stuff becomes unnecessary due to external factors and not due to new features.

altern8 16d ago

Aren't major versions supposed to indicate breaking changes..? That's how I thought semantic versioning worked

theptip 15d ago
Concretely, TFA lists a bunch of input validation that is being made more strict in the default configuration.
suddenlybananas 16d ago
>The reason we bump this major version is that we can get rid of design decisions made in the past that currently block us and then we want to change defaults to more sensible settings that will benefit a greater audience I don't know how to read this sentence other than "there are breaking changes we want to make"
- altern8 15d ago
  I see. Just making sure I had it right :-)
  - winniewinnie 15d ago
    [flagged]
- magicmicah85 15d ago
  The migration guide does say there are breaking changes, but the interpretation I have is "this won't have new features but allows us to develop new features".
cassianoleal 15d ago
Not every product uses SemVer
- winniewinnie 15d ago
  But Polars does: https://docs.pola.rs/development/versioning/ https://docs.pola.rs/development/versioning/ > Polars adheres to the semantic versioning specification: And it does have breaking changes in 2.0. The original asker presumably missed that. E: On the other hand, that whole page on versioning seems inconsistent.