I will then build a release and get it ready for voting either today or tomorrow.
On 11/09/2018 12:26 PM, Josh Elser wrote:
name-version-src.tar.gz for source tarballs (and name-version.tar.gz for "binary" tarballs) is what I'm used to seeing. I don't think it matters much either way :)On 9/10/18 6:27 PM, Francis Chuang wrote: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 anotice 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 namingof the tarball.I'm impressed with the keeping up of the rapid changes in Go. I'm learninga lot by following the work you have been doing keeping the avatica-go library up to date. Kevin RisdenOn 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 someenhancements. I'll wait for more discussion around whether we shouldrename the tarballs before creating a release for vote. The inconsistentfilename 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'sunlikely anyone has built yoolinh expecting a particular filenamestructureat 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 anduse the WithContext() method for HTTP requests. This does means therelease will be 3.2.0 rather than 3.1.1 as we need to follow semver tonot break package managers. I also noticed that avatica-go release are namedapache-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 forthis 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 wasreleased with support for Go modules. Go modules is the official and new way to manage dependencies for Go projects. Support for Go moduleslanded 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 thedependencies, I noticed that the Go tool chain was pulling in v3.1.0for 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'spossible to use 2 different versions of a given library in a programto gradually migrate to the newer version. For Go modules, once alibrary'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.modfile would contain the path "modulegithub.com/apache/calcite-avatica-go" and code importing the library would use "github.com/apache/calcite-avatica-go". In our case, sinceavatica-go is at v3, the go.mod file contains "modulegithub.com/apache/calcite-avatica-go/v3" and imports would use pathslike "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 thego.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 asituation 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-go3.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 amreluctant to introduce it to avatica-go. I think a good approach wouldbe 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. Ithink this can be implemented as part of CALCITE-2536[2], which I willbring 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
