deprecated.upstream_support vs deprecated.eol_version

[Christopher Chavez]

The deprecated 1.0 portgroup has a `deprecated.eol_version` option, which is currently used in older Python ports.

I am trying to understand the distinction between this option and the existing `deprecated.upstream_support` option, i.e. why adding a new `deprecated.eol_version` option was needed or preferred over adjusting `deprecated.upstream_support` to also refer to unsupported versions.

Some existing usage of `deprecated.upstream_support no` is for unsupported versions, such as older MySQL ports. But it seems whoever added the `deprecated.eol_version` option thought it didn't make sense to use `deprecated.upstream_support no` in ports for unsupported Python versions when Python itself was still maintained.

The distinction seems to be:

- `deprecated.upstream_support no`: the project itself (*any* version, not just the version for the one in the port) is not maintained upstream
- `deprecated.eol_version yes`: the project itself may still be maintained upstream, but not for the version in the port

If having both options is desirable:

I suggest being less specific about “end-of-life”: it only means the version is somehow unsupported by upstream. It should not strictly mean that updates will not be published: for example, MySQL regularly declares versions to be EOL on macOS, but the ports are updated anyway since releases continue to be published for other platforms.

I would also ask whether only one deprecation warning should be displayed in the port notes: although some combinations seem redundant, such as having both `deprecated.upstream_support no` and `deprecated.eol_version yes`, I’m not sure all deprecation reasons are mutually exclusive.

Christopher A. Chavez