[opam-devel] OPAM 1.3 roadmap
Anil Madhavapeddy
anil at recoil.org
Fri Feb 27 09:30:30 GMT 2015
Indeed, and there's also the regular maintenance that takes up an increasing amount of time.
My (high-level) suggestion is to treat the first three features as an *internal* API first, and build them with an eventual plugin API in mind so that they're not all intertwined with the remainder of OPAM. Once the features themselves are working and feature-complete, the plugin (or extension) system becomes much easier.
We're actually at that point already with the depext system (and Roberto's proposal there), so it's just a matter of catching up with a few more usecases such as repo signing and file tracking.
-anil
> On 27 Feb 2015, at 09:10, Louis Gesbert <louis.gesbert at ocamlpro.com> wrote:
>
> We're still discussing the roadmap for 1.3, but let's try to keep it reasonable in scope: we currently have the following "hot" topics:
>
> * repository signing (server-side design and infrastructure, client-side validation ; very likely following TUF)
>
> * package files tracking / package sandboxing
>
> * Windows documentation / support
>
> * a plugin architecture for OPAM extensions
>
> Three of these seem to me like the maximum that could be reasonably put in the single release (and one or two may actually be more reasonable). I am willing to work on all of these and don't want to leave anyone behind, but there is so much one can do in a given time. On the other hand, I may be more comfortable separating an already coded part of OPAM into a plugin rather than designing a plugin mechanism more abstractly.
>
>> A first draft proposal for the depext plugin API is in
>>
>> doc/design/depexts-plugins
>>
>
> Yes, this is a good start, and I already added some notes there.
>
> Cheers,
> Louis
> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel
>
More information about the opam-devel
mailing list