Is 3.1.0 broken due to the internal library version issue? Should we put a notice to not use it? I'm not sure if this is even a problem if we "quickly" release 3.1.1 or 3.2.0.
I have no concerns with releasing a 3.1.1 or 3.2.0. Same +0 on the naming of the tarball. I'm impressed with the keeping up of the rapid changes in Go. I'm learning a lot by following the work you have been doing keeping the avatica-go library up to date. Kevin Risden On Mon, Sep 10, 2018 at 8:22 AM Francis Chuang <[email protected]> wrote: > I got all the changes in. This will be a 3.2.0 as some there were some > enhancements. I'll wait for more discussion around whether we should > rename the tarballs before creating a release for vote. The inconsistent > filename is probably due to my oversight when releasing the first > release (3.0.0), so my apologies. > > On 10/09/2018 8:11 PM, Michael Mior wrote: > > 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 <[email protected]> > 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 > >>> > >
