archiving.md: Amend the periodic pruning process

[kit-ty-kate]

An example of this is:

• pkg.1 (released 3 years ago)
• pkg.2 (released 2 years ago)
• pkg.3 (released within the year)
• pkg.4 (released a month ago)
• pkg.5 (released a month ago as well)

if pkg.4 contains x-maintenance-intent: ["(latest)"], under the current scheme 1, 2, 3 and 4 would be archived.

With this amendment, only 1 would be archived since:

• pkg.5: is the latest, so it is kept
• pkg.4: the newer kept pkg.5 has been released within the year, so it is also kept
• pkg.3: the newer kept pkg.4 has been released within the year, so it is also kept
• pkg.2: the newer kept pkg.3 has been released within the year, so it is also kept
• pkg.1: the newer kept pkg.2 is older than a year so it is free to be archived

[dbuenzli]

I think this is hard to parse. I would suggest (which I think is equivalent):

If the package version falls outside the package's maintenance intent, it is
archived only if the next version exists for at least more than one year in 
the repo.

[raphael-proust]

The conditionals with negation is still hard to parse imo. I'd suggest:

- A package's version is archived if both
    - the package version falls outside the package's maintenance intent and
    - the next-more-recent version has been published at least one year prior to the archiving taking place.

and the next point would be

- For packages flagged with `avoid-version` or marked with `available: false`, a package's version is archived if it falls outside the maintenance intent, regardless of the age of the next version.

Actually, I'll try to think of a better wording even, could likely be improved further.

[avsm]

I'm in favour of this amendment. Keeping packages around for a year seems reasonable.

[hannesm]

I'm fine with such an amendment, but I'd propose to express it as:

If the package version falls outside the package's maintenance intent, it is
archived only if it exists for more than one year in the repository.

This would from your initial example put pkg.2 and pkg.1 into considerations for archiving. For me at least this is easier to understand, and I'm not sure what the benefit for "taking the next version" into account is.

[kit-ty-kate]

I'm fine with such an amendment, but I'd propose to express it as:

If the package version falls outside the package's maintenance intent, it is
archived only if it exists for more than one year in the repository.

This would from your initial example put pkg.2 and pkg.1 into considerations for archiving. For me at least this is easier to understand, and I'm not sure what the benefit for "taking the next version" into account is.

This changes the intent of the amendment quite a bit.
The purpose of thinking about the next version is for example let's say we only had pkg.1, pkg.2 and pkg.5 in the example above. With your interpretation, pkg.1 and pkg.2 would both be archived leaving the non-battle-tested pkg.5 as sole version in the repository, which is what i'm trying to avoid.

[dbuenzli]

@kit-ty-kate I see the intent but doesn't all this become a layer above x-maintenance-intent which perhaps indicates the possibilities in x-maintenance-intent itself are not adequate (or people are using a wrong default).

[hannesm]

As you like. I'm only in favour of this amendment if there's a code contribution to the archiving tooling that implements this amendment (source at https://github.com/hannesm/maintenance-intent-filter). I don't care enough, and won't do any opam-repository-archiving work in the near future, so please move where you like to move with this.

I agree with @dbuenzli that taking "version numbers" and "timestamp" into account is inadequate, and maybe the expressive power of "x-maintenance-intent" (and "x-maintained") is not sufficient and needs to be revised.

It was an interesting experiment, I learned a lot - but I also figure that it is way too stressful for me at the moment. I'm sure you'll find decent solutions.

[hannesm]

If you read this by mail, please see the edits of my above comment via the GitHub web interface.