[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Golang Xen packages and the golang packaging system

  • To: Nick Rosbrook <rosbrookn@xxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Date: Thu, 23 Apr 2020 11:18:40 +0000
  • Accept-language: en-GB, en-US
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=George.Dunlap@xxxxxxxxxx; spf=Pass smtp.mailfrom=George.Dunlap@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxx>
  • Delivery-date: Thu, 23 Apr 2020 11:18:55 +0000
  • Ironport-sdr: QgOmS+sABo5YH0YlVXxGV+YC8w2Di1UAuVssMC8OhOYUG2BWTOLFwKSa+whhjpRGoFnsl8DJLw 8mrxgOq10JvouwTnxL3fRk9401khN9R3AG2/ip0ygEd46ILbXLYHZ8hEavj6OEgmtOUDDDk/w0 jxT05CC/AxuS+BOQ8TaNOpW+El9e/37qrWC9gAS3UCCPe1gfoYbpxqydMTXWFSgzlJzM4AoPMo COd49Oj+j12blSaRrWOkok9ECewaFE6zt2qnUiWmxe7F+kZA2qM/D4wzyHDV1/GFPxMJTsfo8/ 1o0=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHWGNesUpUX4UDcFkSZQD1qmZkhVKiGbqmA
  • Thread-topic: Golang Xen packages and the golang packaging system

> 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 

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 

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.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.