Rename temp::Cfg to temp::Context

[djc]

While reviewing #3754 I was a little surprised to note that the temp::Cfg type was different from config::Config (and then apparently there's also dist::config::Config). As far as I can see temp::Cfg also really doesn't represent "configuration" in the sense that it's input provided by the user or an external process. Renamed it to TemporaryContext instead.

[rami3l]

The intention of the original naming is that it should be referenced with temp::Cfg, although I think Cfg is definitely confusing...

Frankly speaking I would personally prefer temp::Context, but since we already have other stuff like download::DownloadCfg I think this is acceptable as well.

[rami3l]

BTW pedantically speaking we should have a BREAKING marker on the commit message that changes the API name :)

[djc]

Frankly speaking I would personally prefer temp::Context, but since we already have other stuff like download::DownloadCfg I think this is acceptable as well.

That's fair -- changed it to temp::Context instead.

BTW pedantically speaking we should have a BREAKING marker on the commit message that changes the API name :)

Why? Is there anything tracking those? IIRC we don't even pretend to have a stable library API. (FWIW in the many projects that I maintain none use BREAKING markers in commit messages.)

[rami3l]

BTW pedantically speaking we should have a BREAKING marker on the commit message that changes the API name :)

Why? Is there anything tracking those? IIRC we don't even pretend to have a stable library API. (FWIW in the many projects that I maintain none use BREAKING markers in commit messages.)

@djc I agree with you that we don't have a stable set of external APIs. OTOH I do have the impression somewhere down the issue threads there's a post saying in the long run we're moving this way... but I failed to find the exact location. Anyway, I think it'd be better to just forget about what I said on this one for now 🤦‍♀️

[rami3l]

@djc There seems to be a conflict with #3763 that went undetected by GitHub but has been caught by the CI. (Thanks, GHMQ!)

[rbtcollins]

 @djc I agree with you that we don't have a stable set of external APIs. OTOH I do have the impression somewhere down the issue threads there's a post saying in the long run we're moving this way... but I failed to find the exact location. Anyway, I think it'd be better to just forget about what I said on this one for now 🤦‍♀️

We don't have an external API at all.

I think we should have a process interface that is machine readable - e.g. protobuf - but not a use-as-library interface, since we have little to no evidence that there is a need for a library interface.

So there is no need to pay a compatibilty tax on APIs