Skip to content

Consider removing the preferred versions feature #1374

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

Open
grayjay opened this issue Mar 28, 2025 · 6 comments
Open

Consider removing the preferred versions feature #1374

grayjay opened this issue Mar 28, 2025 · 6 comments

Comments

@grayjay
Copy link
Contributor

grayjay commented Mar 28, 2025

@phadej and @gbaz suggested removing preferred versions in #1345, so I'm opening a new issue to discuss whether the feature is still needed. Is there a use case for preferring a version that is not the latest, when the latest version shouldn't simply be deprecated?

@grayjay
Copy link
Contributor Author

grayjay commented Mar 28, 2025

cc @ffaf1 @Mikolaj

@ffaf1
Copy link
Contributor

ffaf1 commented Mar 28, 2025

Popular packages which have a “preferred version” on Hackage: amazonka, hxt, hspec, webdriver.

So let me ping @sol, @brendanhay, @UweSchmidt, @erratic-pattern and ask this question:

Is there a cogent reason why you used “preferred version” in the past? Would your package maintainership be hindered if Hackage were to remove (for the future) such possibility?

@brendanhay
Copy link

The reason is lost to time, so no, it would not be hindered for amazonka.

@sol
Copy link
Member

sol commented Mar 28, 2025

I think I used this a long time ago to kind of soft deprecate versions < 2.

As long as cabal gives strong preference to the latest version then I think I'm good.

@grayjay
Copy link
Contributor Author

grayjay commented Mar 28, 2025

I just found a mailing list thread linked to from haskell/cabal#401 that mentions two other reasons: https://groups.google.com/g/fa.haskell/c/w53KJZqUie8/m/vtNcO54iorEJ

Actually it does that for specific packages, there's a file in the
hackage index called 'referred-versions':

base < 4
parsec < 3
HaXml == 1.13.*
QuickCheck < 2

These are all cases where there are large numbers of packages that fail
to specify an upper version constraint but break when built with the
later version of the package. In the case of HaXml it is also because
the 1.13 series is the one considered stable by its author.

I think that the use case of protecting packages without upper bounds is probably made obsolete by Hackage metadata revisions.

@UweSchmidt
Copy link

UweSchmidt commented Mar 28, 2025 via email

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

5 participants