Hi Doug,
Consider this a drive by comment, but you might be able to create a version
of the nested module that does not have any code in it, and set up a
requirement cycle between the nested module and a new parent version.
I think there’s a general approach of creating a requirement cycle f
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,
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 <
golang-nuts@googlegroups.com> wrote:
> The followin
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
