You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@beam.apache.org by "Robert Burke (JIRA)" <ji...@apache.org> on 2018/11/08 00:02:00 UTC

[jira] [Commented] (BEAM-5379) Go Modules versioning support

    [ https://issues.apache.org/jira/browse/BEAM-5379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16679089#comment-16679089 ] 

Robert Burke commented on BEAM-5379:
------------------------------------

Poked this for a bit.  The current beam approach of "all the things are on the same version" mean that if we do migrate to Go Modules, we need to jump straight from v1 to v2 to "catch up" with the tagged releases that beam uses, which means all imports would need to change to match.

That will be a headache for the early adopter users, but could be handled with a small gorename line probably for them to run.

On the plus side, Beam already uses a matching semantic versioning with a leading v for the tags so that's a non-issue.
https://github.com/golang/go/wiki/Modules#modules

> Go Modules versioning support
> -----------------------------
>
>                 Key: BEAM-5379
>                 URL: https://issues.apache.org/jira/browse/BEAM-5379
>             Project: Beam
>          Issue Type: Improvement
>          Components: sdk-go
>            Reporter: Robert Burke
>            Priority: Major
>          Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This would make it easier for non-Go developers to update and test changes to the Go SDK without jumping through hoops to set up Go Paths at first.
> Right now, we us the gogradle plugin for gradle to handle re-producible builds. Without doing something with the GO_PATH relative to a user's local git repo though, changes made in the user's repo are not represented when gradle is invoked to test everything.
> One of at least the following needs to be accomplished:
> * gogradle moves to support the Go Modules experiment in Go 1.11, and the SDK migrates to that
> * or we re-implement our gradle go rules ourselves to use them, 
> * or some third option, that moves away from the GO_PATH nit.
> This issue should be resolved after deciding and implementing a clear versioning story for the SDK, ideally along Go best practices.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)