[MirageOS-devel] Versioning

[Richard Mortier <richard.mortier@xxxxxxxxxxxx>]

All; This came up and after some discussion was then deferred in the
call today. I think it's worth thinking about this a bit before we hit
the next round of omg-we're-about-to-release panic :)

There are currently several things that a "version of Mirage" might refer to:

1. `mirage --version`, ie., the version reported by the CLI tool which
is (now) tied to the version of the `mirage` package in OPAM. This
appears to be, de facto, what users think of as the "version of
Mirage". Currently 2.6.1 as of Dave's latest merge I believe.

2. The set of package constraints output by `opam info mirage`, ie.,
the package versions that the code auto-generated by the CLI tool
requires. This is intimately tied to 1 as it changes when packages
changes requiring the code autogenerated by the CLI tool needs to
change. But it's currently not quite identical to 1, as OPAM metadata
for a package may be (and has been?) updated without revving the
package version.

3. The `1` in `V1_LWT` in `mirage-types`.

4. The version number that we announce when we claim a release. I
believe the next one is due to be "v3".

5. (Coming Soon!) The version of `functoria`, per @drup, the backend
for code generation which will soon be separate from the specific
combinators implemented in the CLI tool itself.

I think this situation is confusing, and I think it is only going to
get more confusing as time passes unless we make some conscious
decisions about what a "version of Mirage" means. In particular,
changes to 1/3/5 may require users' `config.ml` files to change; and
changes to 2 may require their unikernel code to change. 4 is a
publicity thing as far as I can tell and, to a large extent,
dissociated from the others.

For a specific case where this might matter, per the call today, it
seems that there will be some (minor) breakage of users' `config.ml`
syntax when the functoria PR is merged into `mirage`. The two main
proposals seemed to be:

+ we update the CLI tool to 3.0.0 as that will clearly signal to users
that their `config.ml` may be broken; or
+ we update the CLI tool to 2.7.0 as we're not ready to release
"Mirage v3" (ie., an increment of 4 in the list above).

(Either way we update the "breaking changes" page on the website.)

On reflection my own strawman would be that we tie 1,2,4 together by
revving the major version on an "announced release", revving the minor
version every time the CLI tool changes, and revving the point release
when the package constraints change; we deal with 5 by making it just
a pacakge constraint a la 2, and we simply stick with "V1_LWT" for now
just in case we ever want to support more than one set of types.

At this point I'm throwing the floor open. Does anyone have any views
/ opinions on this?  Think it's not a problem?  Got proposals for
solutions?  etc...

-- 
Richard Mortier
richard.mortier@xxxxxxxxxxxx

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel