Hi all, Also, for reference, here are three other related issues:
#26640 "cmd/go: allow go.mod.local to contain replace/exclude lines" https://github.com/golang/go/issues/26640 #26377 "proposal: cmd/go: module semantics in $GOPATH/src" https://github.com/golang/go/issues/26377 #27542 "cmd/go: support simultaneous edits of interdependent modules" https://github.com/golang/go/issues/27542 --thepudds On Sunday, September 9, 2018 at 4:57:38 PM UTC-4, thepud...@gmail.com wrote: > > Seth and/or Mirko, > > What would you think about one of you opening a new issue that covers the > possible approach you were outlining earlier in this thread: > > "Another idea is to have a sort of "publish local" semantics, where the > go tool has support for something like <version>-devel tags, which override > the <version> defined in go.mod. So then you would "publish" the next > version to your local mod cache (just creating/updating the module of the > special version), and the go tool would then make use of that." > > and > > "Publishing to the local cache is how Maven, a build tool for Java, > does it. There is the concept of snapshot versions. For Golang maybe > stating master (or any other branch) as version would be fitting. Then your > CI could use a master checkout as well." > > At least, I don't see an issue suggesting that approach... > > It could be worth it to jot down some quick thoughts on how you would > envision that working. > > --thepudds > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
