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 firstname.lastname@example.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel