Yep, of course. (I sometimes get the feeling that a less good way people do this is by just not documenting the feature :o)
Excerpts from Paolo G. Giarrusso's message of 2016-07-17 04:27:14 -0700: > Edward Z. Yang <ezyang <at> mit.edu> writes: > > > 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. > > Important nitpick: to do that, experimental features should be > marked as experimental and this policy should be made explicit. > That'd be kinder to the one user who starts using it without > realizing. > > I guess that goes without saying (probably in ways I don't > realize), but hey :-D > _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
