3 ms·
While it is true that some of those problems are real, this level of rudeness is just not acceptable. Especially the accusation of "inbreeding". One thing that
by aristidb 14y ago
While it is true that some of those problems are real, this level of rudeness is just not acceptable. Especially the accusation of "inbreeding".
One thing that is wrong is the lack of "semantic versioning". There is the Package Versioning Policy (http://www.haskell.org/haskellwiki/Package_versioning_policy http://www.haskell.org/haskellwiki/Package_versioning_policy), and most packages now adhere to it. Granted, its prescriptions differ from "semantic versioning", and some people disagree that Haskell packages should specify such restrictive versioning boundaries all the time.
(The PVP essentially says that for a version a.b.c.d, every change of a or b means that the API might have changed. Now it might be that most packages are not even affected by the change...)
- dllthomas 14y agoI admit, not having published a haskell package yet, that I've only done a shallow reading of the PVP - is it actually incompatible with semantic versioning or orthogonal? That is, is it possible in the general case to adhere to both? If not, are they incompatible in most cases or very few?
- aristidb 14y agoThis is the biggest difference (quote from semver.org): "Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API. It MAY include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented." Meanwhile the PVP lets you get away with just updating the minor version there.
- dllthomas 14y agoOh, I realize that PVP does not require everything semantic versioning does. It sounds like PVP requires nothing semantic versioning forbids, nor vice-versa? In which case, you could (and, I would assert, should) follow both.