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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
