Another API stability plea

[Conrad Parker]

On 23 August 2010 12:28, Alexander Dunlap <alexander.dunlap at gmail.com> wrote:
> 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.

I think these are separate issues: a pacakge would still need to
specify its versioning constraints. At least the developer should be
able to specify versions of dependent libraries which are known to not
work correctly (ie. include known bugs which affect this package, or
have functions with similar name and type but different semantics),
regardless of whether they build correctly.

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

Yes :)

Conrad.