What should USES=go:1.XY mean going forward?

Hi, Go community,

Through the hard work of committers (I esp. want to call out the work of
des) and contributors, there are basically no uses of pinned versions
anymore. I would never take tools away if they are used for purposeful
benefit, but I also don't want to hand people a tool if literally the
only use is shooting themselves in the foot.

I'd like to hear your opinion on how to handle single-version pins going
forward. The ideas I have are:

[ ] go:1.XY is the same as 1.XY+
[ ] go:1.XY produces a WARNING
[ ] Do nothing and maintain the status quo (i.e. silently change go:1.XY to
go:1.XY+ when go:1.<XY+2> is added to the tree)
[ ] Deprecate and remove pinned ports when their pinned version is removed
[ ] Your idea(s) here: _____________

I'm eager for opinions on any or all of the above, including new solutions.

The WARNING idea is the kind that causes a multi-second delay while the
message is displayed, unless you have WARNING_WAIT=0, when USES=go:1.XY is
used, recommending using 1.XY+ instead. WARNINGS are relevant directly to
maintainers who test-build their ports, making it targeted. It displays
nothing to end-users, which is good (it's a maintainer issue, not an
end-user issue) and bad (the port's lifetime would be limited, and
end-users have no way of knowing that).

I'm not sure if there is a valid use-case for pinned versions anymore?
Should 1.XY simply mean 1.XY+? It's probably more meaningful to end-users
to annotate something that can only ever build with 1.XY with
EXPIRATION_DATE=<release of 1.(XY+2)>. End-users never see WARNINGS

At this point, I feel like the above (1.XY implicitly means 1.XY+) produces
the best outcomes for end-users, maintainers, committers, and the Go team.


-- 
Adam Weinberger
adamw@adamw.org