Repository navigation
"Patch level" release 1.0.1.3 changes generated random sequences #14
Description
Activity
ok, so what you're proposing is
for version X.Y.Z.Q, the result of a given seed should be fixed as Q varies (ie bug fixes shouldn't change behavior). AgreementI think that its not clear if changing how a seed generates an RNG should be considered a Minor or Major change (if the api is otherwise still the same), but yeah, it does seem 1.0.1.3 should be deprecated and a 1.0.2 or 1.1 should be uploaded. (because bug fixes shouldn't change behavior)
i guess it could be argued that the seeds are a "serialization" format, and the PVP policys that relate to changes in Serialization Format kinda things applies. (not sure what that would be mind you)
Agreed that we should address this in the versioning.
- added a commit that references this issue
on Mar 2, 2020 - added a commit that references this issue
on May 19, 2020
E.g.
fst . random $ mkStdGen 23 :: Word8generates5with1.0.1.1but91with1.0.1.3.I think changes to the external behavior of a library are essential and should be reflect in the version number. This is even more true if those changes do not lead to type errors!
From my perspective the version number should be
1.1.0.The issue with patch level releases in general is that they are not detectable with CPP
#ifs. For that reason I only use them in situations where I'm verify confident that no behavior changed whatsoever (usually only for version bumps in the cabal file or documentation changes).I'm not entirely sure whether it's worth to fix this now. For me it's mostly important that we prevent situations like this in the future.
If we want to fix it we could e.g.:
1.0.1.3on Hackagebase)1.1.0