blob: aa6260f63c82ee1b7a8d0c7e3c1c1dd3ccaa4acd [file] [log] [blame]
# Regression test for and
# @latest, @upgrade, and @patch should prefer compatible versions over
# +incompatible ones, even if offered by a proxy.
[!net] skip
env GO111MODULE=on
# v2.0.0+incompatible exists,
# and should be resolved if we ask for v2.0 explicitly.
go list -m
stdout '^ v2\.0\.0\+incompatible$'
# blackfriday v1.5.2 has a go.mod file, so v1.5.2 should be preferred over
# v2.0.0+incompatible when resolving latest, upgrade, and patch.
go list -m
stdout '^ v1\.'
go list -m
stdout '^ v1\.'
go list -m
stdout '^ v1\.'
# If we're fetching directly from version control, ignored +incompatible
# versions should also be omitted by 'go list'.
# (Note that they may still be included in results from a proxy: in proxy mode,
# we would need to fetch the whole zipfile for the latest compatible version in
# order to determine whether it contains a go.mod file, and part of the point of
# the proxy is to avoid fetching unnecessary data.)
[!exec:git] stop
env GOPROXY=direct
go list -versions -m
stdout '^ v1\.5\.1 v1\.5\.2' # and possibly others
! stdout ' v2\.'
# However, if the latest compatible version does not include a go.mod file,
# +incompatible versions should still be listed, as they may still reflect the
# intent of the module author.
go list -versions -m
stdout '^ v1\.0\.0 v1\.1\.0-pre v1\.2\.0 v2\.0\.0\+incompatible'
# If we're fetching directly from version control, asking for a commit hash
# corresponding to a +incompatible version should continue to produce the
# +incompatible version tagged for that commit, even if it is no longer listed.
go list -m
stdout '^ v2\.0\.0\+incompatible$'
# Similarly, requesting an untagged commit should continue to produce a +incompatible
# pseudo-version.
go list -m
stdout '^ v2\.0\.1-0\.20180717164253-7303f7796364\+incompatible$'
-- go.mod --