# This test illustrates the interaction between lazy loading and downgrading in
# 'go get'.

# The package import graph used in this test looks like:
#
# lazy ---- a
#           |
#           a_test ---- b
#                       b_test ---- c
#
# The module dependency graph initially looks like:
#
# lazy ---- a.1 ---- b.1 ---- c.1
#      \                     /
#        b.3 ---- c.2    b.2
#

apiVersion: release-notes/v2
kind:
  bug-fix
area:
  istioctl
issue:
  - 29183

releaseNotes:
  - |

	Long: `Go mod provides access to operations on modules.

Note that support for modules is built into all the go commands,
not just 'go mod'. For example, day-to-day adding, removing, upgrading,
and downgrading of dependencies should be done using 'go get'.
See 'go help modules' for an overview of module functionality.
	`,

	Commands: []*base.Command{
		cmdDownload,
		cmdEdit,
		cmdGraph,
		cmdInit,
		cmdTidy,

# This test illustrates a case where downgrading one module may upgrade another.
# Compare to the downcross1 test case in cmd/go/internal/mvs/mvs_test.go.

# The package import graph used in this test looks like:
#
# a ---- b
#   \     \
#    \     \
#     ----- c ---- d
#
# The module dependency graph originally looks like:
#
# a ---- b.2
#   \      \
#    \      \
#     ----- c.1 ---- d.2
#
# b.1 ---- c.2
#

// -lang=go1.21

// Copyright 2024 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.

// Note: Downgrading to go1.13 requires at least go1.21,
//       hence the need for -lang=go1.21 at the top.

//go:build go1.13

package p

import "io"

// A "duplicate method" error should be reported for
// all these interfaces, irrespective of which package

# This test illustrates a case where downgrading one module may upgrade another.
# This is the same as mod_get_downup_indirect, but using modules
# with graph pruning enabled (go ≥ 1.17).
# Compare to the downcross1 test case in cmd/go/internal/mvs/mvs_test.go.

# The package import graph used in this test looks like:
#
# a ---- b
#   \     \
#    \     \
#     ----- c ---- d
#
# The module dependency graph originally looks like:
#
# a ---- b.2

# This test illustrates a case where downgrading one module may upgrade another.
# Compare to the downcross2 test case in cmd/go/internal/mvs/mvs_test.go.

# The initial package import graph used in this test looks like:
#
# a ---- b ---- d
#
# The module dependency graph originally looks like:
#
# a ---- b.2 ---- d.2
#
# b.1 ---- c.1
#
# If we downgrade module d to version 1, we must downgrade b as well.

cp go.mod.empty go.mod
go get -u rsc.io/quote@v1.4.0 rsc.io/sampler@v1.0.0
go list -m all
stdout 'rsc.io/quote v1.4.0'
stdout 'rsc.io/sampler v1.0.0'
! stdout golang.org/x/text

# downgrading away quote should also downgrade away latemigrate/v2,
# since there are no older versions. v2.0.0 is incompatible.
cp go.mod.orig go.mod
go list -m -versions example.com/latemigrate/v2

go get rsc.io/sampler@none
stderr '^go: downgraded rsc.io/quote v1.5.2 => v1.3.0$'
stderr '^go: removed rsc.io/sampler v1.3.0$'
! stderr '^go get.*golang.org/x/text'
cmp go.mod go.mod.downgrade

# When removing or downgrading a requirement, 'go get' also prints a message
# for explicit dependencies removed as a consequence.
cp go.mod.usequote go.mod
go get rsc.io/quote@v1.5.1
stderr '^go: downgraded rsc.io/quote v1.5.2 => v1.5.1$'

# Commands used to debug the module graph should not write go.mod or go.sum
# or report errors when those files need to be updated.

# Everything's okay initially.
go list -m all

# Downgrading sampler makes go.mod inconsistent, but 'go mod graph',
# 'go mod verify', and 'go mod why' still work.
cp go.mod go.mod.orig
go mod edit -require=rsc.io/sampler@v1.2.0
cp go.mod go.mod.edit
! go list -m all
stderr 'updates to go.mod needed'

go mod graph