Opening up Cabal development

Edward Z. Yang ezyang at mit.edu
Sun Jul 17 17:57:07 UTC 2016


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
> 


More information about the cabal-devel mailing list