Re: Golang Xen packages and the golang packaging system

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On Apr 22, 2020, at 7:55 PM, Nick Rosbrook <rosbrookn@xxxxxxxxx> wrote:
> 
>> 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.

So the way we have things right now, I don’t think #1 is actually possible: If 
you have Xen 4.14 installed, and you update to a 4.15 version of the generated 
bindings, there will be loads of code trying to marshal structural elements 
that don’t exist yet.

Unless we can think of a good way to have `go build` detect at build-time 
what’s available and compile those out, we’re always going to need a 1-1 
connection between golang xenlight package and the installed Xen version 
(unfortunately).

Hmm… or, could we actually use the reflect package to detect it at runtime?  
That’s annoying because you’re still stuck using the headers compiled in at 
*compile* time.

The other thing to point out is that we can always start with 0.x and then 
switch to 4.14 if we want to; but going the other way is going to be more 
difficult.

I guess we could call it v0.4.14 for now.  If we manage to make it 
backwards-and-forwards-compatible, we can rename it v1.0; if we decide to give 
up on that idea, we could rename them v4.14, v4.15, &c.

 -George