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
