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

Re: [MirageOS-devel] Random thought for an OPAM feature

> One of the problems with doing a Mirage release is the sheer number of
> often-interdependent packages that need releasing at once, and the
> lack of a way to do so atomically. The inevitable breakage seems to
> cause considerable pain if you're unlucky enough to be doing something
> else at the same time (as an increasing number are likely to be, I
> hope!).

To try to reduce that pain, I've created a mirage-dev branch in 
mirage-skeleton. The goal is to have:

- mirage-skeleton's master compiles with base opam (e.g. with packages released 
in opam-repository)
- mirage-skeleton's mirage-dev compiles with 
https://github.com/mirage/mirage-dev.git added as a remote to base opam

So people can still use mirage-skeleton even when we are preparing a release at 
it is the case now. 

Regarding mirage-www:
- mirage-www's master branch compiles with base opam
- mirage-www's PR #317 adds TLS supports and compiles with mirage-dev + base 

The goal is to keep the master branches of mirage-www and mirage-skeleton 
always work fine with base opam, and have a mirage-dev branch on these repo 
when we prepare a bulk release in mirage/mirage-dev.



> A similar thing came up in the call today -- how to handle
> co-versioning of Mirage, its libraries, and mirage-skeleton.
> A thought occurred that one way for users to deal with this relatively
> straightforwardly might be to add the ability for opam to pin packages
> based on a datetime. We might then announce that a release was
> in-progress, and anyone who cared could pin all packages to some
> "safe" time before it began. This would save determining latest
> versions for pinning packages individually.
> Thoughts?
> -- 
> Richard Mortier
> richard.mortier@xxxxxxxxxxxx

MirageOS-devel mailing list



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