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

["Beam JIRA Bot (Jira)" <ji...@apache.org>]

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

Beam JIRA Bot commented on BEAM-5379:
-------------------------------------

This issue is P2 but has been unassigned without any comment for 60 days so it has been labeled "stale-P2". If this issue is still affecting you, we care! Please comment and remove the label. Otherwise, in 14 days the issue will be moved to P3.

Please see https://beam.apache.org/contribute/jira-priorities/ for a detailed explanation of what these priorities mean.


> 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: P2
>              Labels: stale-P2
>          Time Spent: 5h 10m
>  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.
> Edite June 2020:  In particular for cross use with GoGradle, we can set options to avoid gradle's own locking system: See https://github.com/gogradle/gogradle/issues/304
> ```
> installDependencies.enabled = false
> resolveBuildDependencies.enabled = false
> ```
> And we'll likely need to ignore the advice for major versions past v2 adopting modules: https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
> which recommends that we increment the major version. This is mitigated by such a move yielding that first Go Modules version to be in line with the first Non Experimental version of the SDK, so users should do a manual update step for that. Unfortunate, but it's a hard signal that something has happened.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)