On 23 August 2010 11:36, Ashley Yakeley 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.

On 23 August 2010 12:28, Alexander Dunlap wrote:

On Sun, Aug 22, 2010 at 8:07 PM, Conrad Parker wrote:

...

On 23 August 2010 11:36, Ashley Yakeley 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@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.

Hello Alexander, Monday, August 23, 2010, 7:28:26 AM, you wrote:

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.

PVP is about ensuring compatibility with future, not-yet-exist versions of library. say, i upload my program that uses SomeLib 1.0 API, and by PVP i request SomeLib 1.* if we don't rely on PVP, i should request SomeLib 1.0 and then, once SomeLib 1.1, 1.2 and so on are released, my cabal file should be updated automatically to mention that my program is compatible with new SomeLib versions another concern is that automatic check cannot ensure unchanged API, it can check only types. If you change API to accept UTF-8 encoded strings instead of Latin1-encoded ones, signatures will remain the same -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On 23 August 2010 14:08, Ivan Lazar Miljenovic wrote:

On 23 August 2010 13:07, Conrad Parker wrote:

...

On 23 August 2010 11:36, Ashley Yakeley 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.

What do you mean by "archive management"?

I meant the management of archives (experimental, unstable etc.) by Hackage.

I believe the point of having it in Hackage as part of the upload process rather than part of the "cabal upload" command (or "cabal check") is that having it as part of Hackage means that they checks can be maintained reliably and transparently without assuming all contributors have the very latest version of cabal-install, and that if extra dependencies (e.g. haskell-src-exts) is needed to perform these checks then they don't become dependencies of cabal-install.

yup, I agree with that :)

Also, this can be pre-checked before uploading: http://hackage.haskell.org/packages/upload.html

Yes, those things that can be pre-checked before uploading should be. This corresponds to something like lintian for Debian (http://lintian.debian.org/). Conrad.

On 23 August 2010 14:41, Ivan Lazar Miljenovic wrote:

On 23 August 2010 15:36, Conrad Parker wrote:

...

On 23 August 2010 14:08, Ivan Lazar Miljenovic

...

What do you mean by "archive management"?

I meant the management of archives (experimental, unstable etc.) by Hackage.

Oh, an indication of a package's stability and having a separate package listing for experimental packages?

I think in terms of Hackage, just having a stable/experimental division should be sufficient without an extra "unstable" middle ground: experimental indicates that you're working on something new (and hopefully cool) that you want feedback on but shouldn't actually be used for real code yet.

Yup, it's all about the expectation that users can get. Debian also started with only 2 levels (unstable, stable) and gradually added the others as the need arose. Conrad.