[
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)
