-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(non-enforced) section on prerelease versions? #42
Comments
I think it would be nice to also add the even/odd convention as between "official" and "experimental" releases as well. These could both live in the FAQ (https://pvp.haskell.org/faq/) rather than the PVP proper, along with any other sort of non-binding best-practices suggestions. |
Note that ghc 9.4.0.20220501 isn't committed to any permanent index (e.g. not uploaded to Hackage). And in fact isn't necessarily PVP compliant (i.e. EDIT: Another similar scheme would be to have |
IMHO this practice is not widespread enough to make it a recommendation. Essentialy, only GHC and Cabal stick to it, not even |
Since PVP doesn't have explicit support for prereleases, there are a few techniques that have been practiced in the community, e.g. GHC:
9.4.0.20220501
This allows PVP compliant update once the real
9.4.1
is released.I don't think the spec should enforce any of that, but what if we provide this as a non-enforced practice recommendation.
VSCode has something similar, where
major.EVEN_NUMBER.patch
marks a release andmajor.ODD_NUMBER.patch
marks a pre-release: https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensionsSo in our terms,
X.Y.EVEN_NUMBER.<date-number>
is the pre-release forX.Y.ODD_NUMBER
or somesuch?The text was updated successfully, but these errors were encountered: