Skip to content
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

Open
hasufell opened this issue May 5, 2022 · 3 comments
Open

(non-enforced) section on prerelease versions? #42

hasufell opened this issue May 5, 2022 · 3 comments

Comments

@hasufell
Copy link
Member

hasufell commented May 5, 2022

Since PVP doesn't have explicit support for prereleases, there are a few techniques that have been practiced in the community, e.g. GHC:

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 and major.ODD_NUMBER.patch marks a pre-release: https://code.visualstudio.com/api/working-with-extensions/publishing-extension#prerelease-extensions

So in our terms, X.Y.EVEN_NUMBER.<date-number> is the pre-release for X.Y.ODD_NUMBER or somesuch?

@gbaz
Copy link
Contributor

gbaz commented May 5, 2022

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.

@phadej
Copy link
Collaborator

phadej commented May 5, 2022

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. ghc lib interfaces might well change still). But it's clever workaround to make ghc <9.4 or ghc >=9.4 checks behave as it if was 9.4 release. (Some project use foo-9.3.20220501 convention, which doesn't work well, but they really want to have foo-9.4.0 as a proper first release, still maintaining linear versions and not using tags - which PVP doesn't even have).

EDIT: Another similar scheme would be to have ghc-9.4.1.20220501 then say ghc-9.4.1.20220606 for beta and ghc-9.4.1.20220720 for final proper release. The version is "ugly", but IMHO that's where versioning systems and marketing needs clash. C.f. build numbers in Windows software.

@Bodigrim
Copy link
Collaborator

Bodigrim commented May 5, 2022

I don't think the spec should enforce any of that, but what if we provide this as a non-enforced practice recommendation.

IMHO this practice is not widespread enough to make it a recommendation. Essentialy, only GHC and Cabal stick to it, not even base or any other boot package. Making such recommendation at this stage of ecosystem evolution would be a source of constant confusion about stability expectations. People struggle to follow PVP as is, I don't want to make it worse.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants