Dependencies/backwards compatibility in Hackage
Sven Moritz Hallberg
sm at khjk.org
Thu Feb 1 15:39:22 EST 2007
Ross Paterson <ross at soi.city.ac.uk>, 2007-02-01 17.45 +0000:
> With version numbers, it suffices that each author has a rule of
> incrementing at a certain level if compatibility is broken. It need
> not be the same level for different packages (though that would be
> less confusing).
> They might have two levels of compatibility: merely
> adding functions, types or classes will not break any clients that use
> explicit imports.
Yes, good point. In fact, I didn't think of the fact that adding functions
etc. can also break an importer. :/ It might indeed be a good idea to be
able to distinguish these two levels. Already requiring old versions
when just an export is added might not offer much benefit to treating
all versions incompatible to each other in the first place...
Actually, upon pondering the fact that it's impossible to enforce the
usage of a particular numbering scheme, it occured to me: We could just
make version numbers following the standard scheme (whichever exactly)
syntactically distinguishable from the current form. Then cabal-install
could work happily with its new information and we don't have to
/impose/ a mandatory scheme on everyone.
(We could, however, apply some leverage towards "persuading" authors to
use the new scheme by emitting a warning from Cabal when it's not used.)
Is this a good idea? Suggestions for what "standard-scheme" version numbers
could look like? (Coolest look wins!)
More information about the cabal-devel