commit 9f34991c038ca38ca54a43232b9cae1c14a3f1e3 · anil.recoil.org/opam-repository

+3 -3

CONTRIBUTING.md

···

       171
       171
        
       Governance

     

       172
       172
        
       ----------

     

       173
       173
        
       

     

       174
       174
       -
       The current points of contact and the full list of maintainers is available in [wiki/Governance](https://github.com/ocaml/opam-repository/wiki/Governance).

     

       175
       175
       -
       Informations about the infrastructure is available in [wiki/Infrastructure-info](https://github.com/ocaml/opam-repository/wiki/Infrastructure-info).

     

       174
       174
       +
       The current points of contact and the full list of maintainers is available in [./governance/README.md](./governance/README.md).

     

       175
       175
       +
       Information about the infrastructure is available in [wiki/Infrastructure-info](https://github.com/ocaml/opam-repository/wiki/Infrastructure-info).

     

       176
       176
        
       

     

       177
       177
        
       Typically maintainers gather weekly to discuss ongoing topics, review PRs together and train maintainers in training.

     

       178
       178
        
       If you wish to help and become an opam-repository maintainer, you can send a message to the maintainers listed above and you will be invited to the next meeting in which they will explain how things work.

     
···

       181
       181
        
       --------

     

       182
       182
        
       

     

       183
       183
        
       Maintainers enforce a certain number of policies applied on packages in opam-repository.

     

       184
       184
       -
       You can read about them in [wiki/Policies](https://github.com/ocaml/opam-repository/wiki/Policies).

     

       184
       184
       +
       You can read about them in [./governance/policies/](./governance/policies/).

     

       185
       185
        
       

     

       186
       186
        
       How to deal with CI

     

       187
       187
        
       -------------------

+42

governance/README.md

···

       1
       1
       +
       # opam Repository Governance

     

       2
       2
       +
       

     

       3
       3
       +
       This directory holds documents codifying the governance of the opam package

     

       4
       4
       +
       repository.

     

       5
       5
       +
       

     

       6
       6
       +
       ## Policies

     

       7
       7
       +
       

     

       8
       8
       +
       See the [./policies/](./policies/) directory.

     

       9
       9
       +
       

     

       10
       10
       +
       ## Maintenance

     

       11
       11
       +
       

     

       12
       12
       +
       ### Main active maintainers

     

       13
       13
       +
       

     

       14
       14
       +
       You are very likely to interact with those maintainers when publishing your package. Don't

     

       15
       15
       +
       hesitate to get in touch with them if you have questions about the publishing process,

     

       16
       16
       +
       the CI results, or something else.

     

       17
       17
       +
       

     

       18
       18
       +
       - [@mseri](https://github.com/mseri)

     

       19
       19
       +
       - [@raphael-proust](https://github.com/raphael-proust)

     

       20
       20
       +
       - [@shonfeder](https://github.com/shonfeder)

     

       21
       21
       +
       - [@haochenx](https://github.com/haochenx) (in training)

     

       22
       22
       +
       - [@arbipher](https://github.com/arbipher) (in training)

     

       23
       23
       +
       

     

       24
       24
       +
       To contact the maintainers in a more synchronous way you can join the [#opam-repository channel on the OCaml Discord](https://discord.gg/vDH7bMjjYW)

     

       25
       25
       +
       

     

       26
       26
       +
       ### Full list of all maintainers

     

       27
       27
       +
       

     

       28
       28
       +
       - everyone listed above

     

       29
       29
       +
       - [@avsm](https://github.com/avsm) (repository administrator)

     

       30
       30
       +
       - [@samoht](https://github.com/samoht) (repository administrator)

     

       31
       31
       +
       - [@dinosaure](https://github.com/dinosaure)

     

       32
       32
       +
       - [@damiendoligez](https://github.com/damiendoligez)

     

       33
       33
       +
       - [@djs55](https://github.com/djs55)

     

       34
       34
       +
       - [@hcarty](https://github.com/hcarty)

     

       35
       35
       +
       - [@yallop](https://github.com/yallop)

     

       36
       36
       +
       - [@dra27](https://github.com/dra27)

     

       37
       37
       +
       - [@smorimoto](https://github.com/smorimoto)

     

       38
       38
       +
       - [@dbuenzli](https://github.com/dbuenzli) (triage)

     

       39
       39
       +
       - [@axrwl](https://github.com/axrwl) (triage)

     

       40
       40
       +
       - [@octachron](https://github.com/Octachron)

     

       41
       41
       +
       - The opam developement team (for safe-keeping)

     

       42
       42
       +
       - [@kit-ty-kate](https://github.com/kit-ty-kate) (former maintainer)

+179

governance/policies/README.md

···

       1
       1
       +
       # opam Repository Policies

     

       2
       2
       +
       

     

       3
       3
       +
       This document lists the explicit policies governing the maintenance and curation

     

       4
       4
       +
       of the opam repository.

     

       5
       5
       +
       

     

       6
       6
       +
       *NOTE*: This policy is not static and will be updated as needed.

     

       7
       7
       +
       

     

       8
       8
       +
       <a name="policy-0"></a>

     

       9
       9
       +
       ## 0. Packages must meet the criteria for inclusion

     

       10
       10
       +
       

     

       11
       11
       +
       Packages in this repository should meet the [criteria for inclusion](./archiving.md#inclusion-criteria)

     

       12
       12
       +
       enumerated in the [archiving policy](./archiving.md).

     

       13
       13
       +
       

     

       14
       14
       +
       ## 1. Removal of packages should be avoided

     

       15
       15
       +
       

     

       16
       16
       +
       #### Exceptions:

     

       17
       17
       +
       

     

       18
       18
       +
       * Packages that no longer satisfy [policy 0](#policy-0).

     

       19
       19
       +
       * In case of a mistake, reverting a PR is allowed if the revert happened reasonably soon after the merge (e.g. < 1 day), to make sure a minimal number of users have pulled the repository in a state where the PR was in.

     

       20
       20
       +
       * Packages that are irredeemably broken can be marked with `available: false`

     

       21
       21
       +
       * Packages whose author want inaccessible for security reasons can be marked with `available: false`

     

       22
       22
       +
       * Packages whose author want gone from opam-repository can make their case with a PR marking them with `available: false`. If the package(s) in question are not used by any other packages the PR should be good to merge, otherwise, a case by case basis, at the discretion of the opam-repository maintainers, is applied.

     

       23
       23
       +
       * Case by case basis

     

       24
       24
       +
       

     

       25
       25
       +
       #### Reasoning:

     

       26
       26
       +
       

     

       27
       27
       +
       * Users should be able to rely on any versions that have ever been available without breakage.

     

       28
       28
       +
       * Users that use opam < 2.1.6 or opam < 2.2.0~beta2 on macOS can sometimes lack GNU patch. The default macOS patch command does not support removal of files and would make `opam update` fail.

     

       29
       29
       +
       

     

       30
       30
       +
       ## 2. Packages should not be modified in a way that makes it uninstallable with an existing and working setup

     

       31
       31
       +
       

     

       32
       32
       +
       #### Exceptions:

     

       33
       33
       +
       

     

       34
       34
       +
       * Known security issues with a combination of dependencies

     

       35
       35
       +
       * Non-deterministic or hard to properly fix failures

     

       36
       36
       +
       * Case by case basis

     

       37
       37
       +
       

     

       38
       38
       +
       #### Reasoning:

     

       39
       39
       +
       

     

       40
       40
       +
       * Users should be able to rely on any versions that have ever been available without breakage.

     

       41
       41
       +
       * Users should be able to keep the packages that they have installed if they are working fine.

     

       42
       42
       +
       

     

       43
       43
       +
       ## 3. Packages should provide some sort of utility for users

     

       44
       44
       +
       

     

       45
       45
       +
       #### Exceptions:

     

       46
       46
       +
       

     

       47
       47
       +
       * Case by case basis

     

       48
       48
       +
       

     

       49
       49
       +
       #### Reasoning:

     

       50
       50
       +
       

     

       51
       51
       +
       * Packages providing very little utility (e.g. one module with just one function defined as a one liner) do not seem justified to go in opam-repository and take one of the available names and space in the git repository that every user has to download

     

       52
       52
       +
       * opam-repository is a curated package repository, we hope to provide useful packages for the large majority of OCaml users

     

       53
       53
       +
       

     

       54
       54
       +
       ## 4. Namesquatting practices and misleading names are forbidden

     

       55
       55
       +
       

     

       56
       56
       +
       #### Exceptions:

     

       57
       57
       +
       

     

       58
       58
       +
       * Case by case basis

     

       59
       59
       +
       

     

       60
       60
       +
       #### Reasoning:

     

       61
       61
       +
       

     

       62
       62
       +
       * Being misled when installing a package is pretty frustrating for users.

     

       63
       63
       +
       * If a package has a compatible interface as another and users mixup their name often, it can become a security risk.

     

       64
       64
       +
       * Developers spending time on a software, to find a package with the same name exists in opam-repository already and was added with malicious intents by another person, would be extremely frustrating for the developer and confusing for users if the project had been publicly announced prior.

     

       65
       65
       +
       

     

       66
       66
       +
       ## 5. Strict dependency constraints should be avoided (=, > or preventive upper bounds)

     

       67
       67
       +
       

     

       68
       68
       +
       #### Exceptions:

     

       69
       69
       +
       

     

       70
       70
       +
       * Strict equality constraints with packages that live in the same source repository (`{= version}`) are accepted (and even encouraged) if the maintainer in planning to publish all the packages in that repository at once everytime there is some change. While this leads to a number of packages that are the same as their previous versions, this simplifies releases for maintainers that are in those cases, and makes the link simpler between the tag in their source repository and the version number in opam-repository.

     

       71
       71
       +
       * Early `<` constraints are allowed if it is known for sure that the package will not be compatible with said upcoming version or to prevent likely runtime failures with a next major version for example.

     

       72
       72
       +
       * Case by case basis

     

       73
       73
       +
       

     

       74
       74
       +
       #### Reasoning:

     

       75
       75
       +
       

     

       76
       76
       +
       * Strict constraints (in particular `=` and `<=`/`<`) make the user experience worse by disallowing the combination of several packages requiring different strict dependencies in the same opam switch.

     

       77
       77
       +
       * Strict constraints also make the work of opam-repository maintainers harder by the sheer number of PR that would simply change the constraints of a package.

     

       78
       78
       +
       * Strict constraints also make testing of the opam ecosystem worse by not testing the new releases of packages against packages that might be compatible with them (reverse dependencies, aka. revdeps).

     

       79
       79
       +
       * It is prefered to use `>=` over `>` when writing dependency constraints because it makes constraints easier to read in most cases and would include potential package revisions or point-releases. For example `> "1.0.0"` would also include a potential `1.0.0-1` revision in the future, and `> "0.9"` would also include a potential `0.9.1` release that might not exists at the moment and that might not include the fix you need.

     

       80
       80
       +
       * It is prefered to use `<` over `<=` when writing dependency constraints because it would ignore any revision packages. For example `<= "1.0.0"` would not take into account a potential `1.0.0-1`, and `<= "0.9"` would not take into account a potential `0.9.1` release.

     

       81
       81
       +
       

     

       82
       82
       +
       ## 6. Version numbers should not have a v prefix (not v1.2.0 but 1.2.0)

     

       83
       83
       +
       

     

       84
       84
       +
       #### Exceptions:

     

       85
       85
       +
       

     

       86
       86
       +
       * Packages that are linked with already existing suite of packages that have adopted this version scheme for historical reasons.

     

       87
       87
       +
       * Packages whose maintainers want/need to change the version scheme to a version number that would be below the latest available version. For example `sexplib.113.33.03` was the latest version of that package before Jane Street decided to reset the version scheme for readability reason to `0.9.0`, however 0.9.0 < 113.33.03 so the `v` prefix is here to make sure the order of version is kept, as 0.9.0 < 113.33.03 < v0.9.0. See [the opam manual section on version ordering](https://opam.ocaml.org/doc/Manual.html#version-ordering) for more details.

     

       88
       88
       +
       * Case by case basis

     

       89
       89
       +
       

     

       90
       90
       +
       #### Reasoning:

     

       91
       91
       +
       

     

       92
       92
       +
       * It is much easier for users to write version constraints if they don't have to second guess for each dependencies if the version number contains a `v` prefix or not.

     

       93
       93
       +
       

     

       94
       94
       +
       ## 7. New package names should avoid the ocaml prefix/suffix

     

       95
       95
       +
       

     

       96
       96
       +
       #### Exceptions:

     

       97
       97
       +
       

     

       98
       98
       +
       * Packages relating to the OCaml compiler

     

       99
       99
       +
       * Packages for whom `ocaml` is historically a part of the name and not a simple suffix (e.g. ocamlfind, ocamlgraph, ocamldap, …)

     

       100
       100
       +
       * Packages whose name without the prefix/suffix would evoke something else that might also be an opam package or lack context (e.g. ocaml-lsp-server, ocaml-manual, …)

     

       101
       101
       +
       * Case by case basis

     

       102
       102
       +
       

     

       103
       103
       +
       #### Reasoning:

     

       104
       104
       +
       

     

       105
       105
       +
       * opam-repository is an OCaml focused repository, so while many projects' name start with `ocaml-` or end with `-ocaml`, if all of their package name would also include `ocaml` it would quickly become fairly annoying and redundant for users.

     

       106
       106
       +
       

     

       107
       107
       +
       ## 8. Developement packages (e.g. pointing to a git branch) are to be avoided

     

       108
       108
       +
       

     

       109
       109
       +
       #### Exceptions:

     

       110
       110
       +
       

     

       111
       111
       +
       * OCaml compilers and related packages related to a fast moving branch are exempt

     

       112
       112
       +
       * Case by case basis

     

       113
       113
       +
       

     

       114
       114
       +
       #### Reasoning:

     

       115
       115
       +
       

     

       116
       116
       +
       * Maintaining the metadata for many developement packages would mean too much work for the opam-repository maintainers.

     

       117
       117
       +
       * The resulting package would be too brittle and would break easily

     

       118
       118
       +
       * On the user's side, such package would lack checksum and thus have to be redownloaded and kept uptodate, everytime they do `opam update`

     

       119
       119
       +
       

     

       120
       120
       +
       ## 9. Packages should only depend on packages they depend on at build time or runtime

     

       121
       121
       +
       

     

       122
       122
       +
       #### Exceptions:

     

       123
       123
       +
       

     

       124
       124
       +
       * Case by case basis

     

       125
       125
       +
       

     

       126
       126
       +
       #### Reasoning:

     

       127
       127
       +
       

     

       128
       128
       +
       * opam-repository currently strives to make installation as lightweight as possible for users of those packages. If a package were to install dependencies that is only used by (for example) developers of said package, it would be detrimental to their user experience, by having to compile and install packages they're not going to use. Example of such packages are: `ocamlformat`, `merlin`, …. Which are in 99% of cases only required when developing a package. For people who want to install developement dependencies however, opam 2.2 introduced the `with-dev-setup` variable.

     

       129
       129
       +
       

     

       130
       130
       +
       ## 10. Binary packages should be avoided

     

       131
       131
       +
       

     

       132
       132
       +
       #### Exceptions:

     

       133
       133
       +
       

     

       134
       134
       +
       * Case by case basis

     

       135
       135
       +
       

     

       136
       136
       +
       #### Reasoning:

     

       137
       137
       +
       

     

       138
       138
       +
       * opam is a source based package manager, it is not currently designed to handle portable binary packages properly.

     

       139
       139
       +
       * As it currently stands adding a binary package would require the facilities to ensure compatibilities with subarchitectures (e.g. x86_64 v1, …) which we do not have.

     

       140
       140
       +
       * opam-repository currently strives to provide the same experience regardless of your platform. Binary package would go against that as each platform would have to be packaged separately, or downloaded all together and sort which one to use on site. Either of these solutions would make the user's experience worse and the maintainers life worse as well.

     

       141
       141
       +
       

     

       142
       142
       +
       ## 11. Changes to a package's source archive are prohibited

     

       143
       143
       +
       

     

       144
       144
       +
       #### Exceptions:

     

       145
       145
       +
       

     

       146
       146
       +
       * Case by case basis

     

       147
       147
       +
       

     

       148
       148
       +
       #### Reasoning:

     

       149
       149
       +
       

     

       150
       150
       +
       * opam-repository packages are expected to be able to install at any time. Packages have a checksum to verify there hasn't been any malicious or unexpected changes to the archive after downloading it. If the source archive were to be changed, everyone who tries to install it would only receive failures, and even if it was fixed in a subsequent PR, it would still break users who have not used `opam update`.

     

       151
       151
       +
       

     

       152
       152
       +
       ## 12. Extra-files are prohibited (patches in the `files/` subdirectory)

     

       153
       153
       +
       

     

       154
       154
       +
       The [extra-files field](https://opam.ocaml.org/doc/Manual.html#opamfield-extra-files) is not allowed in this repository. Please use [extra-source](https://opam.ocaml.org/doc/Manual.html#opamsection-extra-sources) if you need to include external files.

     

       155
       155
       +
       

     

       156
       156
       +
       #### Exceptions:

     

       157
       157
       +
       

     

       158
       158
       +
       * No exceptions

     

       159
       159
       +
       

     

       160
       160
       +
       #### Reasoning:

     

       161
       161
       +
       

     

       162
       162
       +
       * opam-repository is trying to use a minimal amount of files and size, thus any files not required are prohibited.

     

       163
       163
       +
       * For cryptographic signing of the repository, not allowing extra-files reduces the complexity thereof.

     

       164
       164
       +
       

     

       165
       165
       +
       See the [announcement](https://discuss.ocaml.org/t/ann-opam-repository-policy-change-checksums-no-md5-and-no-extra-files/14720) and [discussion](https://github.com/ocaml/opam-repository/issues/25876) for further details.

     

       166
       166
       +
       

     

       167
       167
       +
       ## 13. Weak hash algorithms (md5) are prohibited

     

       168
       168
       +
       

     

       169
       169
       +
       To prepare opam-repository for signing, adding only weak hash algorithms as checksums is prohibited.

     

       170
       170
       +
       

     

       171
       171
       +
       #### Exceptions:

     

       172
       172
       +
       

     

       173
       173
       +
       * No exceptions

     

       174
       174
       +
       

     

       175
       175
       +
       #### Reasoning:

     

       176
       176
       +
       

     

       177
       177
       +
       * Weak hash algorithms would induce that cryptographic signatures would be weak, or would need another set of checksums. This is costly and convolutes the repository.

     

       178
       178
       +
       

     

       179
       179
       +
       See the [announcement](https://discuss.ocaml.org/t/ann-opam-repository-policy-change-checksums-no-md5-and-no-extra-files/14720) and [discussion](https://github.com/ocaml/opam-repository/issues/25876) for further details.

+102

governance/policies/archiving.md

···

       1
       1
       +
       # opam Repository Archiving Policy

     

       2
       2
       +
       

     

       3
       3
       +
       *NOTE*: This policy is not static and will be updated as the process matures.

     

       4
       4
       +
       

     

       5
       5
       +
       ## Terminology

     

       6
       6
       +
       

     

       7
       7
       +
       - The primary opam repository, (referred to here as the "primary repo") is located at [ocaml/opam-repository](https://github.com/ocaml/opam-repository). The primary repo is curated to ensure that compatible packages are co-installable on as many supported platforms as possible, and it is the default package repository.

     

       8
       8
       +
       - "Primary repo criteria" refers to the criteria used to decide whether a version of a package is suitable for continued inclusion in the primary repo.

     

       9
       9
       +
       - The archive opam repository, (referred to here as the "archive repo")" is located at [ocaml/opam-repository-archive](https://github.com/ocaml/opam-repository-archive) and records packages that were once in the primary repo, but no longer meet the primary repo criteria.

     

       10
       10
       +
       - "Supported platforms" are those listed under [Tier 1 and Tier 2 by the OCaml compiler](https://github.com/ocaml/ocaml?tab=readme-ov-file#overview)

     

       11
       11
       +
       - A package's "maximum compiler version" is the upper bound of the OCaml compiler versions supported by a package. Support is derived either based on explicit version bounds set on the `ocaml` dependency in a package's dependency cone, or implicitly based on failed installs detected through our CI and health check processes.

     

       12
       12
       +
       - The "compiler cutoff threshold" is an OCaml compiler versions stipulated by the opam repository maintainers. It sets a lower bound on the compiler versions supported by the primary repo. 

     

       13
       13
       +
       - A package is said to "meet the compiler cutoff threshold" iff its maximum compiler version is greater then or equal to the compiler cutoff threshold.

     

       14
       14
       +
       - The "maintenance intent" of a package refers to the explicitly declared intent of a maintainer to support versions of a package, recorded in the packages `opam` file metadata.

     

       15
       15
       +
       

     

       16
       16
       +
       ## Policy

     

       17
       17
       +
       

     

       18
       18
       +
       ### Compiler cutoff threshold

     

       19
       19
       +
       

     

       20
       20
       +
       The current compiler cutoff threshold is `4.08`.

     

       21
       21
       +
       

     

       22
       22
       +
       This threshold is subject to change by the opam repo maintainers based on the oldest compiler available on maintained distributions.

     

       23
       23
       +
       

     

       24
       24
       +
       <a name="inclusion-criteria"></a>

     

       25
       25
       +
       ### Criteria for inclusion to the primary repo (the default `opam-repository`)

     

       26
       26
       +
       

     

       27
       27
       +
       A version of a package may be published on the primary repo, and will continue to remain listed there, so long as the following criteria hold:

     

       28
       28
       +
       

     

       29
       29
       +
       1. The package meets the compiler cutoff threshold.

     

       30
       30
       +
       2. The sources of the package version are available.

     

       31
       31
       +
       3. The package version falls within a package's maintenance intent, or is a dependency of a package satisfying the primary repo criteria.

     

       32
       32
       +
       4. The package version is installable on at least one of the supported platforms. (Note that it is not required that CI tests are passing, since working installation may require manual system configuration.)

     

       33
       33
       +
       

     

       34
       34
       +
       Note that this property is transitive along a package's dependency tree: if a package satisfies the primary repo criteria, then its dependencies do as well. 

     

       35
       35
       +
       

     

       36
       36
       +
       ### Periodic pruning process

     

       37
       37
       +
       

     

       38
       38
       +
       At regular intervals, no less than every six months, the opam repo maintainers will reevaluate all packages to determine if they satisfy the [primary repo criteria](#criteria-for-inclusion-to-the-primary-repo-the-default-opam-repository). Packages that do not will be subject to archiving, according to the following process:

     

       39
       39
       +
       

     

       40
       40
       +
       - If the package version falls outside the package's maintenance intent, it will be archived.

     

       41
       41
       +
       - The package version's maintainers will be notified of the intent to archive.

     

       42
       42
       +
         - Maintainers will have two weeks to fix the version so that it satisfies the criteria or approve of the archiving.

     

       43
       43
       +
         - If two passes without hearing from the maintainers, the package will be marked as unmaintained and a call for a new maintainer will be submitted to the community via [discuss.ocaml.org under the opam-repository topic](https://discuss.ocaml.org/tag/opam-repository).

     

       44
       44
       +
         - If a new maintainer steps forward, they will have 1 week to fix the package version.

     

       45
       45
       +
         - Otherwise, the package will be archived.

     

       46
       46
       +
       

     

       47
       47
       +
       

     

       48
       48
       +
       ### Archiving a package

     

       49
       49
       +
       

     

       50
       50
       +
       When it has been decided that a set of package versions (aka "versions") should be archived, archiving will proceed according to the following process:

     

       51
       51
       +
       

     

       52
       52
       +
       - A PR will be made to add the archived versions to the archive repo. 

     

       53
       53
       +
           - The opam file of each version will be extended as follows:

     

       54
       54
       +
               - Any dependencies without upper bounds will have upper bounds added, recording the latest available version of the dependency in the primary repo at the time of archiving.

     

       55
       55
       +
               -  The field `x-reason-for-archiving` will be added.

     

       56
       56
       +
               -  The field `x-opam-repository-commit-hash-at-time-of-archiving` will be added.

     

       57
       57
       +
       - A PR will be made to remove the versions from the primary repo:

     

       58
       58
       +
         - The removal PR should link to the corresponding archiving PR.

     

       59
       59
       +
         - The commit message should have the title `Archive packages` and its body should contain the hash of the commit that adds the packages to the archive.

     

       60
       60
       +
       - A announcement will be made on discuss.ocaml.org

     

       61
       61
       +
       - After waiting 1 week for feedback, the PRs will be merged.

     

       62
       62
       +
       

     

       63
       63
       +
       ### Specification of the `x-` fields used in the archiving process

     

       64
       64
       +
       

     

       65
       65
       +
       - `x-reason-for-archiving`:

     

       66
       66
       +
           - Allowed values: a list of containing one more of the following strings

     

       67
       67
       +
             `ocaml-version`, `source-unavailable`, `maintenance-intent`, or

     

       68
       68
       +
             `uninstallable`.

     

       69
       69
       +
           - Meaning: Records the unmet [primary repo criteria](#inclusion-criteria)

     

       70
       70
       +
             motivating the archiving, as follows:

     

       71
       71
       +
               1. `ocaml-version`: The package no longer met the compiler cutoff threshold.

     

       72
       72
       +
               2. `source-unavailable`: The sources of the package version became unavailable.

     

       73
       73
       +
               3. `maintenance-intent`: The package version falls outside of a

     

       74
       74
       +
                  package's maintenance intent, and it is not a dependency of a package

     

       75
       75
       +
                  satisfying any of the primary repo criteria.

     

       76
       76
       +
               4. `uninstallable`: The package version is not installable on any

     

       77
       77
       +
                  of the supported platforms.

     

       78
       78
       +
           - Example: `["ocaml-version", "source-unavailable"]`

     

       79
       79
       +
       - `x-opam-repository-commit-hash-at-time-of-archiving`:

     

       80
       80
       +
           - Allowed values: a string

     

       81
       81
       +
           - Meaning: Records the commit hash of the primary repo at the time a package version is archived.

     

       82
       82
       +
           - Example: `"ca32ab3b976aa7abc00c7605548f78a30980d35b"`

     

       83
       83
       +
       - `x-maintenance-intent`:

     

       84
       84
       +
           - Allowed values: a list of strings matching version numbers, possibly using the special keywords `(latest)`, `(any)` and `(none)`

     

       85
       85
       +
           - Meaning:

     

       86
       86
       +
               - Expresses the declared intent of the maintainers to maintain only certain versions ranges of a package.

     

       87
       87
       +
               - The value of the `x-maintenance-intent` on the latest published package will precedence.

     

       88
       88
       +
           - Examples:

     

       89
       89
       +
               - `["(latest)"]` the maintainer will only maintain the latest version

     

       90
       90
       +
               - `["(latest)" "(latest-1)"]` the maintainer will only maintain the latest `X.Y.Z` version and `(X-1).Y.Z`

     

       91
       91
       +
               - `["(latest)" "(latest).(latest-1)"]` the maintainer will only maintain the latest `X.Y.Z` version and `X.(Y-1).Z`

     

       92
       92
       +
               - `["(any).(latest)"]` the maintainer will maintain every major version X for each X.Y.Z

     

       93
       93
       +
               - `["(latest).(any).(latest)"]` the maintainer will maintain every Y for each X.Y.Z (where X is the latest)

     

       94
       94
       +
               - `["(any)"]` the maintainer will maintain every single version

     

       95
       95
       +
               - `["(none)"]` the maintainer will not maintain any version

     

       96
       96
       +
               - `["1.3"]` the maintainer will maintain the latest  version of "1.3.Z"

     

       97
       97
       +
               - `["2.(latest)"]` the maintainer will maintain the latest minor version specifically of version "2" of the package

     

       98
       98
       +
       

     

       99
       99
       +
       ## References

     

       100
       100
       +
       

     

       101
       101
       +
       - [Package Archiving: Plan](https://github.com/ocaml/opam-repository/wiki/Package-Archiving:-Plan)

     

       102
       102
       +
       - [Originating issue and discussion](https://github.com/ocaml/opam-repository/issues/23789)