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

Make 4.08 the oldest recent version #81

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

shonfeder
Copy link

@shonfeder shonfeder commented Mar 2, 2025

ocaml/opam-repository#27273 made 4.08 the oldest supported ocaml version for the opam repository. Since 'recent' is specified as

the set that is most reliably tested in the opam package repository.

it should be updated accordingly.

This supersedes #68

@shonfeder shonfeder requested review from punchagan and mtelvers March 2, 2025 23:43
ocaml/opam-repository#27273 made 4.08 the oldest
supported ocaml version for the opam repository. Since 'recent' is
specified as

> the set that is most reliably tested in the opam package repository.

it should be updated accordingly.
@mtelvers
Copy link
Member

mtelvers commented Mar 3, 2025

This is too far-reaching to achieve your goal. Given the description, one could argue that other applications should not use this as their baseline, but ocaml-dockerfile, ocaml-ci, docker-base-image, etc, all do use it. The move to archive portions of opam-repository and set the minimum supported level to 4.08 is distinct from dropping support for < 4.08 in all the other tools. Projects which want to drop support for < 4.08 can add a lower bound. Perhaps the best course would be to create a new definition, say opam_repository_minimum, which limits the versions to 4.08 and above and use that in opam-repo-ci.

@shonfeder
Copy link
Author

As noted, this suggestion is based on the explicit description of the specification of this value:

the set that is most reliably tested in the opam package repository.

It sounds like you are arguing that the meaning of this value should be changed. We can correct the documentation and introduce a new value for this purpose, as you suggest.

What you propose as the correct definition of the recent value if its current definition is deemed to be incorrect?

But also, as a sanity check, why should we not raise the floor on these services at this point? Do we have any particular stakeholders who have clear, motivating needs for us to maintain older versions as "recent"? This revives a recent conversation, but it should probably be answered at some point and documented. The redefinition of this critical value might be a good opportunity to do so.

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

Successfully merging this pull request may close these issues.

2 participants