True. That depends a lot on what package we are talking about. You can check whether that is the case for the specific package in question. Have a look at the "Avoiding Singleton Problems" section of Russ' article.
IMO it is the responsibility of the package author to make sure, that different major versions of their package will be able to coexist (by not relying on singletons or explicitly working around it). Obviously, right now that's not the case (as this possibility is new) and we still need to collect some experience with that. If you are in that situation right now, you can have the privilege of helping with that :) After overcoming these birthing problems, the intent is that you can rely on the logic from my last message and make it a patch-release. Is there a specific package you want to talk about? On Wed, Aug 15, 2018 at 12:32 PM 'meta keule' via golang-nuts < golang-nuts@googlegroups.com> wrote: > > Well on the other hand, if the user has the same dependency imported in > the previous version, there might be surpising effects happening, because > she now has two different incompatible versions of the same package. > > If the package is having some init functions that should only be run once > (like the db adapters) that could lead > to unexpected problems since it was just a patch update. > > > -- > 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. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
