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