Comment by benrutter
3 days ago
> 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!
Aren't major versions supposed to indicate breaking changes..?
That's how I thought semantic versioning worked
>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"
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".
I see. Just making sure I had it right :-)
1 reply →
Concretely, TFA lists a bunch of input validation that is being made more strict in the default configuration.
Not every product uses SemVer
But Polars does:
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.
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.
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.
It sounds like they should be on a version much higher than 2.x then.
Deprecating without breaking is fine in a minor version under semver.
4 replies →
> Version bumps should really be about removing deprecated cruft rather than shiny new features.
Can there be deprecated cruft without new features? :-D
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.
Yes, the features don't need to be added immediately.
Good question. I guess sometimes stuff becomes unnecessary due to external factors and not due to new features.
"Tranquil development" (vs. "hype-driven shipping") :)