Perhaps go.mod is not consistent with current version about inbucket HOT 11 CLOSED

from inbucket.

No objections to doing that, I'll wait for any extra clarifications. The v3 directory would be at the top-level of the repo, right? Does this improve compatibility with blaze/bazel?

from inbucket.

Here's what the expert told me, THe expert also gave me a workaround, so I would suggest that you make the next version comply with the standard, and I'll use the workaround for now.

This repository is using a non-standard versioning scheme which causes confusing behavior when trying to import it using standard Go tooling.

See https://go.dev/ref/mod for details on how modules and versioning works.

This repository has a go.mod file (https://github.com/inbucket/inbucket/blob/main/go.mod) which gives the module name as github.com/inbucket/inbucket. The name of the module implicitly contains the major version number of the module. Since this name does not contain a version number, it is implicitly v0 or v1.

The latest tagged version of this repository is v3.1.0-beta1. When a tagged version in a repository contains go.mod file, the tag only applies to the module if the major version of the tag matches the major version of the module. In this case, the versions do not match, so the v3.1.0-beta1 tag does not apply.

For backwards compatibility with pre-modules repositories, when a tagged version in a repository does not have a go.mod file, the major versions do not need to match. If the major version is 2 or higher, the Go tooling will add a +incompatible suffix to the version.

If you look at https://pkg.go.dev/github.com/inbucket/inbucket, you will see that the "latest" version is v2.0.0+incompatible. This is because the v2.0.0 tag is for a version that contains no go.mod file. All later tags contain a go.mod with a mismatched major version, and are ignored.

from inbucket.

https://go.dev/blog/v2-go-modules#major-versions-and-module-paths seems to tell us that we need a v3 directory, in spite of my PR. WDYT?

from inbucket.

Not sure, this isn't something I have experience with yet. Looking at the CI failures, I think the first step is going to be to update all the internal import paths to include /v3/ -- if it still doesn't build, then likely we'd need to move things under a v3 subdir.

from inbucket.

Also, if you are wanting to test the build locally outside of google3, you can try make clean test build

from inbucket.

THe new directory is needed. Do you want a PR or do you want to try it?

from inbucket.

FWIW, IntelliJ is also confused by the current situation with the module versus the version.

from inbucket.

It's probably best I do it, since I'll want to verify the docker build and some of the development convenience scripts I use.

from inbucket.

OK, I'll leave it to you and concentrate on TLS.

from inbucket.

I plan to work on this v3 module stuff later this week providing there are no outstanding PRs for me to derail.

from inbucket.