dune / jbuilder: specify the maintenance intent

[hannesm]

Dear Sir or Madam,

as mentioned in the other ticket, it would be great if dune itself could specify what the maintenance intention of dune (and the other opam files in your repository) is. I suspect "(latest)" would be a good choice.

A separate but related question is about "jbuilder": would marking it as "deprecated" (i.e. flags: deprecated) be a good choice - or is there still the expectation that people will use jbuilder?

Please note: if there's a package in opam-repository that is being kept, and relies on an older version of dune / jbuilder, these versions will be kept. So it is completely safe setting the maintenance intent to [ "(latest)" ] -- there won't be any uninstallable packages due to that choice.

Of course if you plan to support the latest major version as well, please set the x-maintenance-intent field accordingly. See the full specification in https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md#specification-of-the-x--fields-used-in-the-archiving-process

Please note that adding x-maintenance-intent in the latest release is sufficient (please feel free to PR such a field directly to the opam-repository).

[maiste]

FMU, and, according to what is written in the wiki regarding the maintenance of Dune, we only maintain the last version of dune (currently 3.17.2). I have added to the agenda of the Wednesday Dune Dev meeting so we can clarify between ourselves the policy regarding Dune release and maintenance cycle.

[maiste]

From the discussion we had during the Dune Dev meeting, it seems that having the maintenance intend as (latest) is the correct one. About jbuilder it seems relevant to mark it as deprecated.

@rgrinberg does it sound good to you?

[rgrinberg]

Sounds good. Thanks for taking care of this

[maiste]

Thanks for the reply: I'll open the PR on opam to add this on Monday.

[Leonidas-from-XIV]

Should this really be (latest) for all packages? I think for packages like stdune the more truthful declaration would be (none).

[maiste]

You are right. I didn't think about it. Apart from dune itself, do we consider the other packages as maintain (apart from dune use case)?

[Leonidas-from-XIV]

I think dune-configurator is definitely a package to be used and depended on by other packages, for the rest I don't know.

@rgrinberg Can you explain why Dune publishes dyn, stdune and many others as separate packages? I'm sure there's some good reason for it but the decision to do so predates my involvement in the project and knowing the intent behind the packages would help explaining the maintenance intent that we expect to put into it.

[rgrinberg]

At some point there was a plan to make these publicly available. At the very least, they were made public to dune-rpc and ocaml-lsp. I don't think much of that is relevant now and we can roll that back if possible. So yeah (none) would be more appropriate.