Hacker News Reader

Comment by cosmic_quanta | Hacker News Reader

In the case of the Haskell ecosystem, I think that achieving this golden rule is hard specifically because not every package conforms to semantic versioning.

For example, the newly released `mtl`, which is a dependency of many other packages, breaks backwards compatibility from version 2.2 to 2.3. Personally, I'd expect to be able to have a dependency requirement like `mtl = 2.*` and forget about it forever.

If package versions were 'updated' to follow semantic versioning (e.g. `mtl` is not implicitly a version 3), we might have a better view of the current level of coherence of the Haskell ecosystem.

View on HN

I don't know how controversial this will be - but I'm wondering whether packages which break semantic versioning should be re-versioned by distributions to 0.X.Y versions (perhaps with a X.Y.? -> 0.X.Y transformation), until they prove themselves willing to maintain API stability enough for an official, community-accepted, non-zero major version.

Specifically for Haskell packages, they are not expected to change their interface on the 0. versions.

What is perfectly reasonable, by the ways, because it makes the schema basically useless. If people did it, very soon all the packages would be free-form 0.X versions, if not by their fault, it would be because of a dependency.

It makes much more sense to forcefully increase the version, instead of decreasing it.

(Also, notice your sibling that explains that mtl strictly followed the numbering convention.)

That's actually correct versioning in Haskell. The Haskell ecosystem uses a different versioning convention from other ecosystems where the first two components of the version number signal breaking changes. For more details, see: https://pvp.haskell.org/

Uh, I stand corrected. I've been developing Haskell for nearly a decade and somehow never saw this.

Thank you for bringing this to my attention!

You're welcome!

Reply on news.ycombinator.com