changes to tested-with field aren't trivial and, hence, are allowed

[ulysses4ever]

fix #1505, see explanation there

[leana8959]

Seems reasonable to me 👍

[gbaz]

I believe that the issue in #583 was described too abruptly, and the fix made in #598 was the intended behavior. before, hackage rejected files that had a different tested-with as revisions, which broke a workflow that changed that.

now, hackage allows different tested-with as long as it is not the only change made.

i.e. it still prevents a revision of a file that just modifies tested-with, and I think that was by design. On the other hand, I don't think it matters that much to prevent this, except to prevent abuse, which is unlikely (and if it occurs we can revert or just yell at the person). In which case this simplifies things.

So that said @ulysses4ever what's your use case here? do you intend to frequently update cabal files whenever packages are tested with newer ghcs?

[ulysses4ever]

@gbaz thank you for the context that I missed. My use case is, indeed, to be able to say that my package supports a new GHC without making a release that otherwise isn't required. I'm not sure what "frequently" could mean here but at most it will be as frequent as new GHC releases. Of course, in practice we do actually make releases once in a while, so it will be less frequent than GHC releases in practice.

[gbaz]

Since each revision has a long-term effect on the size of the index-01 tarball, I think the intent was to not allow this. I'm not sure where I fall on this issue, but its worth thinking through.

[gbaz]

Arguably the (eventual) right design would be to have something like "tested with" but that was not part of the cabal file and instead something that could be modified just in the hackage server store, so without the unfortunate knock-on effects...

On the other hand, I think the amount of people who will be doing this sort of revision will be negligible in the long run, and the ultimate effect on tarball size small.

[ulysses4ever]

Having it as a part of hackage-server metadata sounds reasonable at first but then we get two pieces of data with the same semantics that will always be divergent. Kinda like what we have with the notion of maintainer, which has produced a lot of confusion. I'd prefer to avoid repeating this mistake.

[ulysses4ever]

Since each revision has a long-term effect on the size of the index-01 tarball, I think the intent was to not allow this.

What are the alternatives? I could upload a full-fledged release changing only this field — this is probably even less desirable in terms of the above mentioned size effect. Or is this the official position of Hackage admins that, in the interest of saving the bandwidth, we should abstain from such inconsequential modifications? I personally value this field a lot, because, if maintained properly, it helps me get started with a package. It is a piece of documentation that improves quality of live. It’d be sad to see an explicit discouragement from Hackage to maintain this piece of documentation. But I can live with it. If this is the conclusion, I can close the pr and the issue.

[phadej]

Personally, so far, if I updated tested-with some other field has also changed, most obviously build-depends. If we assume if there would be a time where a new GHC is released without any (major) library version changes (i.e. base is decoupled), then I'd assume that my library would just work.

tested-with is a weird field. It's informative, not normative. haskell-ci "abuses" it, cause it exists and is handy, but still, the field is only informative. haskell-ci could made work without tested-with existing at all.

I'd actively discourage changing just tested-with even if were allowed. EDIT: in particular revisions trash build caches, the less revisions we can have, the better.

[ulysses4ever]

all right, thanks for the input. I guess, we shelve it then.