[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4

[Claus Reinke]

> If the convention for modifying package versions of form x.y.z is:
> - increment z for bugfixes/changes that don't alter the interface
> - increment y for changes that consist solely of additions to the interface, 
> parts of the interface may be marked as deprecated
> - increment x for changes that include removal of deprecated parts of the 
> interface

i like this, but i doubt it will catch on (see my reply to Simon's summary).

> The 'foo' package name is just an indicator of lineage.
> foo-2.xxx is not the same package as foo-1.xxx, it's interface is missing 
> something that foo-1.xxx's interface provided.

yes, that is the troublesome part.

> Dependencies of "foo" shouldn't appear in published cabal files.  There is a 
> case for their use in development where you are specifying that you want to 
> depend on the very latest version of foo available, perhaps from darcs.  When 
> you publish that latest version number gets burned in, eg "foo-2.1.20071016".

agreed, because of your point above. though i think we'll need 
to find a similarly convenient replacement.. or we'll be changing 
old cabal files forever.
 
> As for provides/expects and imported-modules instead, isn't that just an 
> arbitrary line drawn in the granularity sand?
> Perhaps package versions could be expanded to include the type of every 
> function they expose, plus more information to indicate which bugfix version 
> of those functions is present.  That's maybe the Right Way... and probably a 
> lot of work.

as with all type systems, there is a balance between preciseness,
decidability, and useability. just adding an imported-modules: field
would do no harm (like the exposed-modules: field, it should be 
inferred), but it would allow cabal to make better choices.

in the context of the base split, or similar api refactorings, package
names don't tell us much, package versions at best tell us that there
is a problem (and may not even tell us that); if existing packages
had an additional imported-modules: field, cabal could try to suggest
alternative providers - in the current case, that would be the new
base and its spin-off packages. then the user could just accept
those alternatives, and be happy.
 
claus