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
_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
