I'd like to understand the expectations of library maintainers better. I am particularly thinking about the reference to setting major versions through import paths, like github.com/go-yaml/yaml/v2.
Is the expectation that library owners would need to change the structure of their project like this when making breaking changes, or is it that vgo will handle this for users behind the scenes? Second, I'd like to understand the proposed workflow when one repo has many subpackages that should be independently versioned. For example, a repo might have a exp/ subdirectory for experimental libraries that are available for adventurous users. Git tags can only identify the version of the whole repo; how will library maintainers signal that different packages have different versions? I think the exp/ case is important but not the only case worth thinking about. It's also important in repos that provide both an installable main package and library code, like github.com/golang/protobuf. They might want to use tags and releases for distributing their binary, and might want to make breaking changes to their command-line API without a breaking version bump for the libraries, or vice-versa. On Tuesday, February 20, 2018 at 9:20:54 AM UTC-8, Russ Cox wrote: > > Hi everyone, > > I have a new blog post you might be interested in. > https://research.swtch.com/vgo. > > I'll try to watch this thread to answer any questions. > > Best, > Russ > > > > -- 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.
