[Haskell] Library versioning policy
Bulat Ziganshin
bulat.ziganshin at gmail.com
Fri Nov 24 06:09:14 EST 2006
Hello haskell,
We all know what is a "DLL hell" - if some program written against
version 2.0 of library, then using version 1.0 or 3.0 of the same
library when program compiled may call all sorts of devil
there is a great solution of this problem - Eternal Compatibility
Theory. unfortunately, it's so great that seldom used on practice
because it requires significant efforts from library developer
i propose another solution for this problem which don't require to
write anything and just impose some policies both for library
developer and user
library developer should just explicitly declare and obey some policy
of incrementing library versions which will allow library user to
select proper range of versions which are guaranteed to work with his
code. i propose the following as standard policy:
* major version change (2.2->3.0) means total incompatibility. all
sorts of changes may come
* middle version change (2.1.3->2.2) means addition of new facilities
(functions, constructors, classes...). in most cases, such
semi-compatible version can be used if that's done with caution
* minor change (2.1.1->2.1.2) means only internal changes and bugfixes
other policies may be used as well, library developer should just
declare his policy at the library birth and use it consistently
this will allow library users to declare in their cabal files range of
library versions they are accepted and be sure that this range will
include latest bugfixes but don't include any incompatible changes.
then Cabal (which now can handle many versions of the same lib) should
select latest acceptable version of library requested and make it
available for compilation
say, if i wrote my program using Streams 1.2.1, i can specify
Build-Depends: Streams 1.2.*
or, if i brave/accurate enough:
Build-Depends: Streams 1.*
and Cabal should select the best library available at build time
--
Best regards,
Bulat mailto:Bulat.Ziganshin at gmail.com
More information about the Haskell
mailing list