[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [MirageOS-devel] 2.0 releases going into mirage-dev
On 3 Nov 2014, at 18:28, Amir Chaudhry <amc79@xxxxxxxxx> wrote: > > > On 3 Nov 2014, at 15:15, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote: > >> I've started tagging all the libraries currently in mirage-dev and have >> uploaded releases of most of them to https://github.com/mirage/mirage-dev. > > Hooray! > >> Next steps: >> - add constraints on packages that would conflict (mostly cohttp) in the >> main opam repo >> >> - figure out why this ocaml-dns downgrade happens only on 4.02: >> https://travis-ci.org/mirage/ocaml-dns/jobs/39791629#L265 >> >> Interesting question is what we do with mirage-dev now. Should we instruct >> people to remove it? It's actually more useful it seems to have remotes for >> a specific purpose (mirage/mirage-2-release) so that once they're done, they >> just contain archives. >> >> If we bump mirage/mirage-dev to the git versions again, then users will >> always get the bleeding edge… > > > I admit I don't fully understand what you're asking but I'll pretend that I > do. :) > > I'd instruct people to remove mirage-dev unless they're happy to be on the > bleeding edge (I'd be one of those that removes it). > > I think we need to maintain clearer separation between mainstream releases in > the default opam repo (which should happen frequently) and making bleeding > edge versions available to devs in a convenient way (which may occasionally > be broken). Anything in between gets complicated to understand. > > My reasoning is that we should avoid having instructions that tell largely > new users to add opam remotes, which also encourages us to make sure we're > releasing often in the main opam repo. It's too easy to add lots of things > into our own remote(s) thus forcing newcomers to join us on the cutting edge > (and suffering the concomitant blood loss). > > I'm not sure what the right way forward is, especially given the pace of > development and number of libs, but I hope you can see what I'm trying to get > at -- also, let me know if I misunderstood the question. I'm inclined to agree with you -- only those interested in the git branches should have to add mirage/mirage-dev. -anil _______________________________________________ MirageOS-devel mailing list MirageOS-devel@xxxxxxxxxxxxxxxxxxxx http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |