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.

Reply via email to