Re: [MirageOS-devel] 2.0 releases going into mirage-dev

[David Sheets <sheets@xxxxxxxxxxxx>]

On Tue, Nov 4, 2014 at 8:06 AM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>
>> On 4 Nov 2014, at 00:01, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
>> wrote:
>>
>>
>> On 3 Nov 2014, at 15:15, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>
>>> 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...
>>
>> +1 to having a set of remotes that act as tags and then keeping mirage-dev 
>> as the HEAD of everything.
>>
>> (+10 for adding support to opam for having a repo tag as a remote if it 
>> doesn't already :) (isn't there some support for accessing branches as 
>> remotes with the # notation ?)
>
> Yes, the git:// syntax supports # for branches or tags.
>
> A remote acting as a tag for a collection of packages with explicit version 
> numbers is interesting, but doesn't quite work.  If the stable repo 
> supersedes the package numbers with new ones, those will get selected instead.

If only we had some way to monitor repositories and sync specific
selectors in opam remotes...

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

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