Opening up Cabal development

Edward Z. Yang ezyang at mit.edu
Thu Jul 14 06:54:19 UTC 2016


Excerpts from Herbert Valerio Riedel's message of 2016-07-13 23:40:06 -0700:
> I.e. write up a specification/proposal outlining motivation (i.e. what
> problem does this solve), specify what the changes are exactly (syntax &
> semantics), what the consequences are, and so on.
> 
> Then we inevitably need some criteria to decide whether a proposal is
> accepted and approved for implementation. This could be formally in the
> hands of the core library committee together with the Hackage trustees
> (since we do have quite some experience with .cabal files and care a lot
> about the Hackage ecosystem).

Why can't we release experimental changes to the Cabal specification?
Neither setup-depends nor convenience libraries went through any formal
proposal mechanism.  If a feature is good people will start using it
and we will have to continue supporting it.  If a feature is bad/not
useful we can yank it from the next release; anyone using an
experimental feature like this isn't trying to maximize their
Cabal compatibility anyway.  And any change to the format with
cabal-install can't parse is not going to be supportable via
custom-setup anyway.

So how about this script, which is how web standards work:

    Cabal changes need to be informally proposed and discussed.
    But the advancer can also write a PR and get it merged in
    as an experimental extension, to be trialed for the next
    major release series.  Eventually it gets standardized.

Edward


More information about the cabal-devel mailing list