String.create: get rid of deprecation warning

[cfcs]

No description provided.

[yomimono]

The build is failing for the package which exercises this change: https://travis-ci.org/mirage/ocaml-vchan/jobs/315142527#L2655

Do you have time to revisit this PR?

[cfcs]

Hmm, I am unable to reproduce that build error.
String.create is an alias for Bytes.create on 4.04.2, perhaps this is not the case with 4.03?

[cfcs]

Ah, it was unrelated to the code change, I think.
- File "lwt/vchan_lwt_unix.ml", line 17, characters 33-61:
module Xs = Xs_client_lwt.Client(Xs_transport_lwt_unix_client)

This is the interface:

val Xs_transport_lwt_unix_client.read Lwt_unix.file_descr -> bytes -> int -> int -> int Lwt.t 

It is building against an old version of xenstore_transport (0.9.6) rather than 1.0.0:
https://github.com/xapi-project/ocaml-xenstore-clients/releases

[hannesm]

@cfcs you can add in vchan*.opam in this repository a {>= "1.0.0"} next to the xenstore_transport dependency! :)

[cfcs]

@hannesm yes, I just pushed a commit that does that, waiting for the CI to see if 4.03 users will be happy now :)

[cfcs]

Ah, shit.
https://github.com/xapi-project/ocaml-xenstore-clients/blob/master/xenstore_transport.opam#L37

Well, there's the problem. I don't know how to proceed. @yomimono @hannesm

[hannesm]

it's pretty easy: drop 4.03 support, and require the same 4.04.0 ;) MirageOS anyways requires 4.04.2 these days.

[hannesm]

so you'll need to update the opam files and also .travis.yml to use a mix of 4.04.2 and 4.05.0 (instead of the 4.03.0)

[cfcs]

@hannesm ;) I didn't feel comfortable killing 4.03 by myself, do we need to ping someone to take a decision? On the other hand I guess it would make sense when the other Xen-related repositories already have a lower bound of 4.04...

[hannesm]

@cfcs there, i pushed a commit onto this PR here... not sure why you specified xenstore_transport {.. < "1.1.0"} -- that's not sth we usually do in opam (instead, we fix up the reverse dependencies upon API breakage)

[cfcs]

Cool! I like upper bounds to prevent breakage (would rather have an unresolvable-constraints-error-in-some-cases-but-works-for-most-users in opam in than broken-for-everyone-until-maintainers-fix-package), but that's just personal preference.

[hannesm]

this LGTM, @djs55 @samoht @avsm seem to be the maintainers (by looking at the number of commits to this repository)!

[samoht]

LGTM