Adding upstream version 1.1.0.upstream/1.1.0upstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 20 insertions, 0 deletions

diff --git a/dependencies/pkg/mod/golang.org/x/exp@v0.0.0-20220613132600-b0d781184e0d/cmd/gorelease/testdata/internalcompat/README.txt b/dependencies/pkg/mod/golang.org/x/exp@v0.0.0-20220613132600-b0d781184e0d/cmd/gorelease/testdata/internalcompat/README.txt
new file mode 100644
index 0000000..e3de7e5
--- /dev/null
+++ b/dependencies/pkg/mod/golang.org/x/exp@v0.0.0-20220613132600-b0d781184e0d/cmd/gorelease/testdata/internalcompat/README.txt
@@ -0,0 +1,20 @@
+Modules example.com/internalcompat/{a,b} are copies. One could be a fork
+of the other. An external package p exposes a type from a package q
+within the same module.
+
+gorelease should not report differences between these packages. The types
+are distinct, but they correspond (in apidiff terminology), which is the
+important property when considering differences between modules.
+
+There are three use cases to consider:
+
+1. One module substitutes for the other via a `replace` directive.
+   Only the replacement module is used, and the package paths are effectively
+   identical, so the types are not distinct.
+2. One module subsititutes for the other by rewriting `import` statements
+   globally. All references to the original type become references to the
+   new type, so there is no conflict.
+3. One module substitutes for the other by rewriting some `import` statements
+   but not others (for example, those within a specific consumer package).
+   In this case, the types are distinct, and even if there are no changes,
+   the types are not compatible.