[FEATURE] Go Vanity URL go-micro.dev

[asim]

Looking at potentially setting up a permanent import URL for go-micro that's totally unrelated to the location of the repo. This is in case there's plans to move it again later but also just to give it a permanent URL.

Currently "go-micro.dev" or "gomicro.dev" are two choices. Looking for feedback on whether people think it's a good idea.

import "go-micro.dev"

[asim]

The domain go-micro.dev now points to this repo with go import meta tags. The next step will be to rename the module and the various package names

[AuditeMarlow]

I would personally prefer the hyphenated version as there's a clear separation of the words "Go" and "Micro". Would renaming the module not be a backwards incompatible change though? In that case we should be handling the rename with great care.

[asim]

Yes it's backwards incompatible but we've made these moves before between versions and orgs. I think what it ensures is long term it doesn't matter where the repo lives and the import should not be tied to github.

[AuditeMarlow]

Just for clarity's sake, the plan is to rename the module from github.com/asim/go-micro/v3 to go-micro.dev? This means omitting the v3 path from the module name, correct?

[asim]

That's correct. I need to actually test this in a separate project to see what affect it has. I am guessing that Go probably still attempts to honour versioning and may reject it.

[asim]

So I'm testing here https://github.com/asim/test-vanity but I can see issues with versioned vanity url usage. This seems to imply that the server returning the meta tags needs to understand the versioning and it can't just be simple github pages. Otherwise versions have to be defined as branches or sub directories. Not ideal. But tbh I'm not a fan on /vX suffixes. Its pretty painful and was only done to deal with breaking changes and in the interest of moving forward quickly. I otherwise prefer evolutionary software that isn't defined by this versioning scheme.

Tough call, hard to go backwards, not otherwise sure how to move forwards besides just using it for unversioned use.

[AuditeMarlow]

Would it be an option for Go Micro to use the go-micro.dev vanity URL and git tags (or releases) for versioning? For example, currently Go Micro's latest version is v3.6.0, so by invoking go get go-micro.dev, your go.mod would be updated with require go-micro.dev v3.6.0. If you require any other version, such as v2, you can just invoke go mod edit -require go-micro.dev@v2.9.1 and your go.mod would be updated with that version instead. This way there's no need to mess around with module suffixes.

[asim]

So I was attempting to do this in my test repo but it seems like Go completely ignores the release tags unless it's v1 or you have versioned the module with /vX. They've very specifically tied the design of go mdo and versioning like this. It's a shame.

[AuditeMarlow]

I see what you mean I think. I've set up my own vanity test here https://github.com/auditemarlow/test-vanity, shamelessly stolen from you but I needed to verify some things, considering you tagged v1.0.0 on the go-nitro.dev/v3 module. /v3 does not imply v1.0.0 so I set up my project without the suffix and tagged v1.0.0. That makes my module's v1.0.0 go getable just fine. It gets complicated when you want to publish versions v2 and beyond. There's a blog post on that here https://go.dev/blog/v2-go-modules

The bottom line I think is that due to the way Go Modules work right now, it's not possible to not have module version suffixes when you want to publish versions v2 and beyond. There's strength in that too though, as it forces you to choose a major version to ensure upgrading (or downgrading) is a conscious decision.

As for Go Micro, we can choose between (at least) two evils; keep the v3.x.x tags and /v3 module suffix or wipe them clean and start fresh with module go-micro.dev. The former sounds like the most feasible solution.

[asim]

I would like to try eliminate the versioned suffix for go-micro.dev but will do a bit more research and have a play before offering any solutions. From a usage perspective I'm not sure what others expect but the versioning in this way is really ugly. The only alternative I think is to make versions sub directories.

[asim]

OK, so I've used nginx to serve the meta info and got it to work. Turns out github pages is not great for this. Now the next question is, how to switch over and whether to preserve this form of versioning or if its time to create v0-9 sub packages.

[AuditeMarlow]

Can this be closed now that we can import go-micro.dev/v4 or are we not yet done migrating everything?

[asim]

I want to test one last thing. I thought submodules don't work but it might be because I'm missing release tags for them. If that's the case I can convert everything. I'm going to test this out either today or tomorrow