opam files: maintenance intention

[hannesm]

Dear Madam or Sir,

thanks a lot for your work on opam.

I've been working on the opam-repository archiving process, we established a policy https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md

Now, opam itself has a lot of packages released to opam-repository, and I'm curious whether you could specify the maintenance intention of opam itself by adding a x-maintenance-intent field to the opam files. Specifying this field in the latest release is sufficient.

In addition, there are various opam pre-releases in the opam-repository - could these be marked with flags: deprecated and be cleaned up in the phase 3 (march 1st)? Or is there value in keeping these pre-releases and beta versions? I did so for the OCaml compilers releases (in ocaml/opam-repository#27153) - and can propose such a PR for the opam pre-releases as well if you like.

Thanks a lot, if you've any questions, don't hesitate to ask.

[hannesm]

A related issue/question is about "opam-lib" - a package which exists in opam-repository, originates from this repository - but is no longer around -- can that be safely marked as deprecated? (existing versions are 0.9.1 0.9.3 0.9.4 0.9.5 1.0.0 1.1.0 1.1.1 1.2.0 1.2.1 1.2.2 1.3.0 1.3.1).

If you say "yes", I can propose a PR for opam-repository.

[kit-ty-kate]

opam-lib can be marked as deprecated indeed, as it is the original library for the long gone opam 1.x. This is done in ocaml/opam-repository#27229
The pre-releases have been also marked as deprecated in ocaml/opam-repository#27228

As mentioned in ocaml/opam-repository#27228 i'm not sure flags: deprecated is the right thing to use to do that. It currently displays a vague note to users: => Note: This package is deprecated. upon installation, which might imply that the package itself was deprecated instead of the version only.
The effort to tag all the versions is quite substantial as well, maybe a side database listing rules could be more indicated than using flags: deprecated and x-maintenance-intent. At the very least the former could be merged into the latter if we had a more rich "intent language" to talk about pre-releases. For example can you think of a solution for this? (this would probably be our maintenance intent if i understand it correctly):

x-maintenance-intent: [
  "2.(any).(latest)"
  "2.(latest).0~(any)" # except here i want to say "match only if 2.(latest).x does not exist"
]

[mseri]

The language for the intent could be improved, we could have

"2.(latest).0~(any) < 2.(latest).(any)"

or something of the sort, to specify only if it was superseded by 2.(latest).(any)