You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Francis Chuang <fr...@apache.org> on 2018/09/10 06:04:39 UTC
[DISCUSS] Towards calcite-avatica-go-3.1.1
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
Re: [DISCUSS] Towards calcite-avatica-go-3.1.1
Posted by Francis Chuang <fr...@apache.org>.
Base on the consensus in this thread (mostly +0s), I will go ahead with
updating the release script to generate tarballs named consistently with
the avatica and calcite tarballs. The main reason I wanted to get this
change in is consistency with the other release artifacts (calcite +
avatica) released by the Calcite project.
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
>> annouce@apache.org 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
>>>> <fr...@apache.org>
>>>> 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
>>>>>> <fr...@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
>>>>>>>>
>>>>>
>>>>>
>>>>
>>
Re: [DISCUSS] Towards calcite-avatica-go-3.1.1
Posted by Josh Elser <el...@apache.org>.
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
> annouce@apache.org 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
>>> <fr...@apache.org>
>>> 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 <fr...@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
>>>>>>>
>>>>
>>>>
>>>
>
Re: [DISCUSS] Towards calcite-avatica-go-3.1.1
Posted by Francis Chuang <fr...@apache.org>.
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
annouce@apache.org 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
>> <fr...@apache.org>
>> 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 <fr...@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
>>>>>>
>>>
>>>
>>
Re: [DISCUSS] Towards calcite-avatica-go-3.1.1
Posted by Josh Elser <el...@apache.org>.
+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 <fr...@apache.org>
> 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 <fr...@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
>>>>>
>>
>>
>
Re: [DISCUSS] Towards calcite-avatica-go-3.1.1
Posted by Kevin Risden <kr...@apache.org>.
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 <fr...@apache.org>
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 <fr...@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
> >>>
>
>
Re: [DISCUSS] Towards calcite-avatica-go-3.1.1
Posted by Francis Chuang <fr...@apache.org>.
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 <fr...@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
>>>
Re: [DISCUSS] Towards calcite-avatica-go-3.1.1
Posted by Michael Mior <mi...@gmail.com>.
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 <fr...@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
> >
>
Re: [DISCUSS] Towards calcite-avatica-go-3.1.1
Posted by Francis Chuang <fr...@apache.org>.
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
>