Another API stability plea

[Alexander Dunlap]

On Sun, Aug 22, 2010 at 8:07 PM, Conrad Parker <conrad at metadecks.org> wrote:
> On 23 August 2010 11:36, Ashley Yakeley <ashley at semantic.org> wrote:
>> On 2010-08-11 13:18, John Goerzen wrote:
>>>
>>> I'm writing because there was an API change in a point release. This is
>>> violating our convention and the Platform policy.
>>
>> I wonder if this could be checked automatically by the Hackage upload
>> process?
>
> I think it'd be useful for Hackage to check this automatically, but I
> think it should be part of the archive management not part of the
> upload process.
>
> As has been randomly suggested before, it would make sense to use a
> model like Debian's of having mulitple parallel archives
> (experimental, unstable, testing, stable), where packages are migrated
> from one to the next after some automated testing. The current Hackage
> policy would roughly correspond to Debian experimental -- a staging
> area from which some autobuild system tries to find packages which it
> can promote to unstable without breaking it.
>
> It may take a while (eg. overnight) to discover that an upload to
> experimental breaks some other package, and during that time there may
> be other uploads. I think it's better to allow developers to upload to
> an experimental staging archive and for Hackage to run overnight
> checks on the whole archive, than to pretend Hackage can find
> breakages instantly and disallow the upload of a package.
>
> cheers,
>
> Conrad.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>

If that happens, is the PVP even needed anymore? If Hackage
automatically checks when packages break, couldn't it automatically
determine upper bounds? Then we wouldn't need the conservative
upper-bound settings.

Of course, it seems like a fairly ambitious proposal to do all this
checking automatically.

Alex