Announcement: v1.0.0 will be released on June 18th

[darccio]

This release doesn't contain code changes.

After 10 years, with many corner cases covered, very few issues pending (at least, comparing them with the usage of the library as part of Docker, Kubernetes, Datadog's agent, etc.), and a very stable API, I think it's time to release a 1.0.0 version.

This version will be released under a vanity URL: dario.cat/mergo

PS: although I'll make sure that github.com/imdario/mergo will be available, I'm going to also change my GitHub handle, so expect for a few minutes to not be able to pull from github.com/imdario as I fork it from the new handle to the old one.

PS2: I'm creating a discussion for this release to make sure we can have a conversation around the topic, and anything else about Mergo that you care about.

---

This discussion was created from the release Announcement: v1.0.0 will be released on June 18th.

[svengreb]

Congratulations in advance for reaching this awesome milestone! 🚀 🎉
And thanks for creating and maintaining such a great library, it saved me so much time and pain in many projects.

The change of your GitHub user handle should work smoothly due to the automatic redirects that are created when a repositories location changes (user, organization or repository name change/transfer).

Just a curious question: What is running behind dario.cat/mergo? A simple Git server or something dedicated for Go modules like e.g. gomods/athens or another implementation (e.g. official package from Go's tool box)?

[darccio]

@svengreb Thanks for the valuable feedback! Although redirection is automatic when a repository location changes, I think it's a good idea to secure my old username just in case somebody malicious registers it again and sets up a fork.

About what will run behind dario.cat/mergo, I was planning to use just some static file, as described here and here. Nothing fancy and easily cacheable in Cloudflare, where I host my website.

[svengreb]

Oh, I thought GitHub also reserves, just like with repositories within the same namespace, a username with redirects, but as the docs say

After changing your username, your old username becomes available for anyone else to claim.

I'm a bit surprised about this design decision by GitHub, but this definitely requires to keep the “old“ account around. Thanks for clarifying this!

Also thanks for the references for “vanity“ import paths. I had something in mind that hosting a Go module is built on top of simple text-based protocols, but making it possible this way sounds great and I'll definitely check it out for my modules 😄

[jerome-laforge]

Hello @imdario,
Any news about this v1.0.0?
Thanks in advance.

[darccio]

@jerome-laforge Sorry, I had some unplanned things to attend and I couldn't finish the release. It's ready and I'll publish it tomorrow morning 08:00 CEST.

I already tested go get -u dario.cat/mergo@a5b2cb8 on a greenfield repo and my static page generator zas.

Thanks for your patience!

[darccio]

And done! https://github.com/imdario/mergo/releases/tag/v1.0.0

[darccio]

1.0.0 went live: https://github.com/imdario/mergo/releases/tag/v1.0.0 Looking forward for your feedback in the release discussion #239

[regnaio]

The move to dario.cat broke go get -u ./... in my project. It looks like I need to check each dependency to see which one uses mergo and needs to make this change..

Does the move to dario.cat pose any security or transparency issues? When importing a package from github.com/, you know that the code you're importing will reflect the code in GitHub, which should make it harder to sneak in malicious code. How can we guarantee and trust that importing from dario.cat will perfectly reflect the code in GitHub?

I'm unsure if the change to dario.cat was a beneficial move for all..

[svengreb]

Nothing changes about where the code lives which is on GitHub. Using a “vanity import path“ simply comes with advantages like being independent from third-parties like GitHub and gain more control over own modules. See the comment above for details how this was done for this module.
You can simply check how it works by running curl -vL dario.cat/mergo which will result in a <meta> tag that is used by the Go toolchain under the hood to resolve to any VCS.

You are not responsible for updating any import paths in your dependencies. Running go mod tidy -v (optionally with -compat=TARGET_GO_VERSION to enforce backwards compatibility) should clean up your dependency graph. You could also enforce the version of this module by using a replace directive to enforce any imports of the “old“ path to change to the new path which is used recursively for all your dependencies.

[phuslu]

yes, but it really a bit ugly, I need to do the "replace" in a number of repos.