If that's true, then I think the wiki should be updated with a better description, shouldn't it? The implication is that it is safe and just the reverse of adding a sub-module, but it doesn't sound like that's the case at all. Is it okay to do if a v1+ release has happened? And in our case, we have no releases to retract -- the go.mod referencing it just specifies its version as a hash.
Is there a way to `exclude` the sub-module? We tried to do something with that, but we weren't able to make it work. On Friday, December 13, 2024 at 9:15:06 PM UTC-8 Sean Liao wrote: > There's no automatic upgrade path, the best you can do is mark the sub > module as retracted and/or Deprecated. your users will need some manual > action to drop it as a dependency. > > - sean > > On Sat, Dec 14, 2024, 13:37 'Doug Fawley' via golang-nuts < > golan...@googlegroups.com> wrote: > >> The following section indicates that it should be possible to safely >> remove a module from a multi-module repository, and move the removed >> module's packages to the parent module: >> >> >> https://go.dev/wiki/Modules#is-it-possible-to-remove-a-module-from-a-multi-module-repository >> >> However, it doesn't say how to accomplish this. >> >> To add a new submodule, the steps are clear: >> >> 1. Create the new module >> 2. Add a dependency on the new module to the parent module >> >> When *merging* two modules, however, there is no way to add a dependency >> to the deleted submodule to refer users to the parent module, and there is >> no way to refer to a deleted version of the submodule from the parent >> module. This results in an ambiguous import if one module in a project >> refers to the parent module at the new version and another module in the >> same project refers to the deleted submodule at an older version. >> >> I had wrongly assumed that if a newer version of the parent module >> included the package, that it would replace the version in the submodule, >> but I now see why that is wrong. But I still don't know how to address the >> issue. Is there some way to add an entry in the parent go.mod that >> indicates that the submodule was deleted? >> >> In case it's relevant, the submodule that was removed in this instance >> was unstable (v0). But we still don't want to break users that were using >> it, since the API didn't change when we incorporated it into the parent >> module and released it as stable. >> >> The specific incident is being tracked here: >> https://github.com/googleapis/google-cloud-go/issues/11283 >> >> Thanks, >> Doug >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/golang-nuts/3103aade-0d28-4274-a83e-3d947485f650n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/3103aade-0d28-4274-a83e-3d947485f650n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/22420db8-da56-4a96-9967-b90c2293f6f0n%40googlegroups.com.