A patch release some sounds good to me. Thanks for staying on top of all this Francis! I'm +0 on renaming the source tarball. I'm assuming it's unlikely anyone has built yoolinh expecting a particular filename structure at this point.
On Mon, Sep 10, 2018, 04:57 Francis Chuang <francischu...@apache.org> wrote: > I have a few minor housekeeping tasks I would like to include in this > release. I want to replace the "golang.org/x/net/context" import path > with just the stdlib "context" package, which has been available since > Go 1.9. This means that we can also get rid of the ctxhttp package and > use the WithContext() method for HTTP requests. This does means the > release will be 3.2.0 rather than 3.1.1 as we need to follow semver to > not break package managers. > > I also noticed that avatica-go release are named > apache-calcite-avatica-go-src-x.x.x.tar.gz, where as Calcite and Avatica > are released as apache-calcite-avatica-x.x.x-src.tar.gz. I think we can > also make future releases apache-calcite-avatica-go-x.x.x-src.tar.gz for > this release if desired. > > Francis > > On 10/09/2018 4:04 PM, Francis Chuang wrote: > > 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 > > >
