Re: Golang Xen packages and the golang packaging system

[Nick Rosbrook <rosbrookn@xxxxxxxxx>]

> One question I have from the above is how the xen.git RELEASE-X.Y.Z should 
> correspond to the vA.B.C in the golang package repo.
>
> The obvious answer, of course, is (A, B, C) = (X, Y, Z); that is, xen.git tag 
> RELEASE-4.14.0 should create a golang package tag of v4.14.0.
>
> The issue with this is that golang assumes you’re using semantic versioning; 
> so a `go get -u` would normally feel justified in upgrading from v4.14.x to 
> v4.15.x.
>
> A couple of possible responses:
>
> 1. Declare that OK.  That would mean not only that we have to have v4.15.x be 
> compatible with golang source code written against v4.14; it would also mean 
> that v4.15.x needs to be able to *compile* against libxl version 4.14.  Which 
> might be a good idea, but we’d want to think carefully before making that 
> kind of commitment.
>
> 2. Declare that people need to use `go get -u=patch` when updating, and/or 
> use go.mod &c to manually restrict the version of go to use to the 
> currently-installed Xen version
>
> 3. Map (A, B, C) = (Y, Z, 0).  (i.e., RELEASE-4.14.5 would make tag v14.5.0 
> .)  `go get` wouldn’t update automatically, but it might be confusing which 
> version *should* be used; particularly if we ever roll over a major version 
> for Xen.
>
> Any other possibilities?
>
> I think I’d start out with #2, and then consider moving to #1 at some point 
> in the future.
>
> Thoughts?

We should also consider aligning with Go module versioning
conventions. For example, right now the package is unstable, so
according to convention we should be in v0.1.x. A "v0" indicates to
the Go ecosystem that, at this stage, we will likely make breaking
changes to the package API. So, tagging v4.14.0 is a bit confusing
since this indicates that we are on the 4th major version of the
package, and that it's stable. See [1] and [2] for more on these
conventions.

However, things are obviously complicated by the fact that the
xenlight package depends on libxl, and following convention might make
that relationship less clear and difficult to track. But, if we stray
from convention we at least need to be clear about it and have a good
explanation why.

That said, unless we can come up with a good way to follow convention
*and* keep the libxl version sorted, I think #2 makes the most sense
right now.

-NR

[1] https://blog.golang.org/publishing-go-modules
[2] https://blog.golang.org/v2-go-modules