Personal tools

Package versioning policy

From HaskellWiki

(Difference between revisions)
Jump to: navigation, search
(EternalCompatibilityInTheory)
(+cat)
Line 1: Line 1:
  +
[[Category:Proposals]]
 
We all know what is a "DLL hell" - if some program written against
 
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
 
version 2.0 of library, then using version 1.0 or 3.0 of the same
Line 45: Line 46:
 
== Related ==
 
== Related ==
   
http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory
+
* http://www.haskell.org/tmrwiki/EternalCompatibilityInTheory

Revision as of 03:32, 14 January 2007

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.2.0 && < 2.0

and Cabal should select the best library available at build time

Related