Hi all,
As announced through the mailing list today, Avatica-Go 3.1.0 was
released with support for Go modules. Go modules is the official and new
way to manage dependencies for Go projects. Support for Go modules
landed in Go 1.11, which was released around 3 weeks ago.
After the Avatica-Go 3.1.0, I proceeded to update a few of my
open-source libraries dependent on avatica-go. While updating the
dependencies, I noticed that the Go tool chain was pulling in v3.1.0 for
the avatica-go library correctly, but was pulling in
v0.0.0-20180828061053-334bc15f92dd for the avatica-go errors subpackage.
This behavior is valid when using Go modules: it's possible to use 2
different versions of a given library in a program to gradually migrate
to the newer version. For Go modules, once a library's version is v2 or
higher, the import paths should be updated as well. For example, if
avatica-go is at v1 or lower, then the go.mod file would contain the
path "module github.com/apache/calcite-avatica-go" and code importing
the library would use "github.com/apache/calcite-avatica-go". In our
case, since avatica-go is at v3, the go.mod file contains "module
github.com/apache/calcite-avatica-go/v3" and imports would use paths
like "github.com/apache/calcite-avatica-go/v3", "module
github.com/apache/calcite-avatica-go/v3/errors" and so on.
The problem is that during the switch to Go modules, I updated the
go.mod file to "module github.com/apache/calcite-avatica-go/v3", but did
not realize that all imports within the library must be updated to
"github.com/apache/calcite-avatica-go/v3" as well. This created a
situation where imports of the subpackages within the library were not
using v3, but the master commit at the time Go modules was enabled:
334bc15f92dd.
Due to this problem, I'd like to propose a patch release: avatica-go 3.1.1.
I also had a look to see what solutions are available to prevent this.
There is a tool[1] that updates all the import paths automatically, but
the tool is currently in WIP status and it is not part of the official
Go tool chain. As the tool is untested and very new, I am reluctant to
introduce it to avatica-go. I think a good approach would be to scan the
files for the string "github.com/apache/calcite-avatica-go" and throw an
error if the expected version currently being released is not in the
string. I think this can be implemented as part of CALCITE-2536[2],
which I will bring forward to avatica-go 3.1.1.
Please let me know what you guys think.
Francis
[1] https://github.com/marwan-at-work/mod
[2] https://issues.apache.org/jira/browse/CALCITE-2536
