You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Remove the "2.0.1.0 > 2.0.1" example, or clarify that this is bad #36
It is true that 2.0.1.0 > 2.0.1 in the lexicographic ordering, because mathematically, a missing number at the end counts as minus infinity. However, in versioning practice, a missing number at the end defaults to 0.
If after 2.0.1 you release 2.0.1.0, it is either by accident, ignorance or spite, in order to confuse others; imo.
There is already a more fundamental discussion at #4, I raised this issue to at least remove or better comment the 2.0.1.0 > 2.0.1 example which could give the idea that such versioning is good practice.
I came across an upper bound shelly < 0.10.0 in the wild: https://hackage.haskell.org/package/c2hs-0.28.8/revisions/
So had I released shelly as 0.10 (rather than 0.10.0 what I did) this major upgrade would have slipped through the fence.
It seems that by analogy to decimal representation, folks naturally expect 0.10.0 == 0.10.
If such equations would hold in general, then versions would be "omega-adic" numbers ($\sum_i a_i*\omega^{-i}$ where $i$ ranges over all natural numbers and each $a_i$ is a natural number).
(EDIT: Less scary concept than "omega-adic" numbers: Polynomials $\sum_i a_i x^{i}$ with natural number coefficients $a_i$ and $0 \leq x < 1$.)
Maybe cabal check should warn if there is a exclusive upper bound with trailing zeros, like < 0.10.0?
Maybe cabal check should warn if there is a exclusive upper bound with trailing zeros, like < 0.10.0?
As long as that doesn't prevents making revisions, as currently revisions cannot introduce more warnings (IIRC). Even the situation where adding < 0.10.0 like bound is not probable, it can happen (and may be caused by an accident, ignorance or spite!)
EDIT: I.e. there should be a way to tell that if there is < 0.10.0 -like bound, I really need that trailing zero, i.e. to make cabal check not complain when it's intentional.
there should be a way to tell that if there is < 0.10.0 -like bound, I really need that trailing zero, i.e. to make cabal check not complain when it's intentional.
If cabal check was configurable by flags to turn off individual warning classes (like GHC is), we could make a separate warning class that could be switched off in the rare cases when such a bound is intended. (Haskell CI could be extended to be able to pass such flags to cabal check.)
(I'd rather not extend the .cabal file format with pragmas to turn off cabal check warnings.)
Activity
phadej commentedon Oct 24, 2021
What concretely you are proposing? Adding an entry to a FAQ, https://github.com/haskell/pvp/blob/master/pvp-faq.md? That would be great.
andreasabel commentedon Feb 6, 2022
I came across an upper bound$\sum_i a_i*\omega^{-i}$ where $i$ ranges over all natural numbers and each $a_i$ is a natural number).$\sum_i a_i x^{i}$ with natural number coefficients $a_i$ and $0 \leq x < 1$ .)
shelly < 0.10.0in the wild: https://hackage.haskell.org/package/c2hs-0.28.8/revisions/So had I released
shellyas0.10(rather than0.10.0what I did) this major upgrade would have slipped through the fence.It seems that by analogy to decimal representation, folks naturally expect
0.10.0 == 0.10.If such equations would hold in general, then versions would be "omega-adic" numbers (
(EDIT: Less scary concept than "omega-adic" numbers: Polynomials
Maybe
cabal checkshould warn if there is a exclusive upper bound with trailing zeros, like< 0.10.0?phadej commentedon Feb 6, 2022
As long as that doesn't prevents making revisions, as currently revisions cannot introduce more warnings (IIRC). Even the situation where adding
< 0.10.0like bound is not probable, it can happen (and may be caused by an accident, ignorance or spite!)EDIT: I.e. there should be a way to tell that if there is
< 0.10.0-like bound, I really need that trailing zero, i.e. to makecabal checknot complain when it's intentional.andreasabel commentedon May 24, 2022
If
cabal checkwas configurable by flags to turn off individual warning classes (like GHC is), we could make a separate warning class that could be switched off in the rare cases when such a bound is intended. (Haskell CI could be extended to be able to pass such flags tocabal check.)(I'd rather not extend the
.cabalfile format with pragmas to turn offcabal checkwarnings.)