Re: [DISCUSS] Towards calcite-avatica-go-3.1.1

Mon, 10 Sep 2018 15:28:14 -0700

3.1.0 will most likely cause trouble for downstream consumers at this point, so I would like to mark it as a "do not use" if there is a protocol for doing so. The announcement got rejected by [email protected] due to the email being corrupt, so I will not be making the announcement there.
I plan to make it clear in the changelog + news item for 3.2.0 to note that 3.1.0 should not be used. Is there anything else that needs to be done? 


I'd also like some opinions as to whether the tarballs should be renamed 
to apache-calcite-avatica-go-x.x.x-src.tar.gz from 
apache-calcite-avatica-go-src-x.x.x.tar.gz.


Francis

On 11/09/2018 6:15 AM, Josh Elser wrote:

+1 to Kevin's concern about 3.1.1 going out with a "don't use 3.1.0" 
if I'm understanding this all correctly. Admittedly, I'm a bit dense 
and haven't spent enough time understanding the problem. (Maybe just 
skip the 3.1.0 announcement if that hasn't gone out yet too)



I trust you to be doing the right stuff for us, Francis! Thanks for 
your diligence and humility in bringing this up to the larger crowd (I 
know it would've been easy to just suggest a 3.1.1 and not admit the 
issue).


On 9/10/18 9:37 AM, Kevin Risden wrote:

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






























					Reply via email to