I've never seen that happen before, but in case it does, only new environments will fail, i.e., those has been building fine will still be building fine. I.e. it's quite easy to correct.
So I personally think that it is really a high price to pay for something that may *never* happen. Of course, not everyone agree with me, as I've seen someone even worries that go yaml (gopkg.in/yaml.v2) will go away someday, and insists vendering it. On Wednesday, August 1, 2018 at 9:50:13 AM UTC-4, nafis wrote: > > How about the Author delete the library. > > On Tuesday, July 31, 2018 at 5:49:36 AM UTC+6, Eric Johnson wrote: >> >> Long term, I suspect you're better off without the vendoring. >> >> Specifically, I suggest looking into automating your libraries tests with >> the earliest possible versions of supported dependencies, and the latest >> versions of dependencies. >> >> With a tool like vgo, it should be possible to have two versions of your >> lock file that your build / test cycle can switch between. If a project >> adds backwards compatible changes, they you can test across major versions >> as well. >> >> Eric >> >> On Saturday, July 28, 2018 at 11:43:04 AM UTC-7, nafis wrote: >>> >>> Suppose I'm making a library and it does reference some other library >>> not part of the standard library. I want to vendor those so that my library >>> doesn't fail if the other 3rd party developer deletes their library or >>> major changes of their library(I know this sound like stupid design). And I >>> want to push the vendor folder on my library repo. My question: Is this >>> the bad idea keep a vendor folder on the library repo. >>> >>> Thank you for your time. >>> >> -- 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.
