else
     # In case of a downgrade, a custom CoreDNS Corefile will be overwritten by a default Corefile. In that case,
     # the user will need to manually modify the resulting (default) Corefile after the downgrade is complete.
     echo "== Applying the latest default CoreDNS configuration =="

	if service.Spec.Type == api.ServiceTypeExternalName {
		return nil
	}

	// We don't want to auto-upgrade (add an IP) or downgrade (remove an IP)
	// PreferDualStack services following a cluster change to/from
	// dual-stackness.
	//
	// That means a PreferDualStack service will only be upgraded/downgraded
	// when:
	// - changing ipFamilyPolicy to "RequireDualStack" or "SingleStack" AND

#
# 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.
# If that downgrade selects b version 1, we will add a new dependency on module c.

cp go.mod go.mod.orig
go mod tidy
cmp go.mod.orig go.mod

go get example.com/d@v0.1.0
go list -m all

go get example.com/a@v1.0.2 go@1.28rc1
go list -f '{{.Module.GoVersion}}'
stdout 1.28rc1
go get go@1.24.2
stderr '^go: downgraded go 1.28rc1 => 1.24.2$'
stderr '^go: downgraded example.com/a v1.0.2 => v1.0.1$'
stderr '^go: downgraded example.com/b v1.0.2 => v1.0.1$'
go list -f '{{.Module.GoVersion}}'
stdout 1.24.2

-- go.mod --
module m
go 1.21

require (
	example.com/a v1.0.0

go mod edit -require example.com/retract/self/prev@v1.1.0
go get example.com/retract/self/prev
go list -m example.com/retract/self/prev
stdout '^example.com/retract/self/prev v1.1.0$'

# 'go get pkg' should not downgrade from a retracted version when no higher
# version is available.
cp go.mod.orig go.mod
go mod edit -require example.com/retract/self/prev@v1.9.0
go get example.com/retract/self/prev

)

var (
	migrateCmd = &cobra.Command{
		Short: "Upgrade/downgrade etcd data across multiple versions",
		Long: `Upgrade or downgrade etcd data across multiple versions to the target version

Given a 'bin-dir' directory of etcd and etcdctl binaries, an etcd 'data-dir' with a 'version.txt' file and
a target etcd version, this tool will upgrade or downgrade the etcd data from the version specified in
'version.txt' to the target version.

### Other notable changes

* kube-up (with gce/gci and gce/coreos providers) now ensures the authentication token file contains correct tokens for the control plane components, even if the file already exists (ensures upgrades and downgrades work successfully) ([#43676](https://github.com/kubernetes/kubernetes/pull/43676), [@liggitt](https://github.com/liggitt))

        succeeds("dependencies", "--configuration", "pmd")
        output.contains "pmd:pmd-java:"

        when:
        buildFile << """
            dependencies {
                //downgrade version:
                pmd "$testDependency"
            }

            pmd {
                incrementalAnalysis = false
            }
        """.stripIndent()

        then:
        fails("check")

apiVersion: release-notes/v2
kind: bug-fix
area: installation
issue:
  - 32749
releaseNotes:
  - |

# This test illustrates a case where an upgrade–downgrade–upgrade cycle could
# add extraneous dependencies due to another module depending on an
# otherwise-unlisted version (such as a pseudo-version).
#
# This case corresponds to the "downhiddenartifact" test in the mvs package.

# The initial package import graph used in the test looks like:
#
# a --- b
#  \     \
#   \     \
#    c --- d
#
# The module dependency graph initially looks like: