Library versioning policy
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@gmail.com
Bulat Ziganshin wrote:
say, if i wrote my program using Streams 1.2.1, i can specify
Build-Depends: Streams 1.2.*
You can already say build-depends: Streams >= 1.2 && < 1.3 The 1.2.* syntax would be just sugar (sugar is nice, though). I think adopting a consistent versioning policy is a good thing, but we (the Cabal designers) didn't want to impose a versioning policy because we felt that doing so would be too restrictive - people often want to be free to choose their own. So I think having a *recommended* policy, and clearly documenting it, is the way to go. Cheers, Simon
Am Freitag, 24. November 2006 12:32 schrieb Simon Marlow:
[...] So I think having a *recommended* policy, and clearly documenting it, is the way to go.
Agreed. But nevertheless, every simple linear (major/minor/...) versioning scheme has some problems, especially when dynamic linking is considered, as elaborated in http://www.linuxshowcase.org/2000/2000papers/papers/browndavid/browndavid_ht... Are our package version numbers as powerful as the symbol sets described there? This could be the case, but I am not completely sure. Cheers, S.
Hello Simon, Friday, November 24, 2006, 2:32:14 PM, you wrote:
Build-Depends: Streams 1.2.*
You can already say
build-depends: Streams >= 1.2 && < 1.3
The 1.2.* syntax would be just sugar (sugar is nice, though).
yes, it is that i mean. the only real question - is Cabal selects *latest* version when there are few in requested range, say 1.2.0, 1.2.1, 1.2.3 ? to be exact, when one use Stream 1.2.1, he should request either Build-Depends: Streams 1.2.* or Build-Depends: Streams >= 1.2 && < 2.0 (1.* will not work in general because new functionality may be added in middle versions)
I think adopting a consistent versioning policy is a good thing, but we (the Cabal designers) didn't want to impose a versioning policy because we felt that doing so would be too restrictive - people often want to be free to choose their own.
So I think having a *recommended* policy, and clearly documenting it, is the way to go.
"other policies may be used as well, library developer should just declare his policy at the library birth and use it consistently" to be exact, policy may be changed at any point where no backward compatibility is promised, i.e. for standard policy - on any major version also i should add that standard policy for libraries not reached 1.0 version should be * no promises for 0.8 -> 0.9 * backward compatible for 0.8 -> 0.8.1 * bug-fixes and internal changes for 0.8 -> 0.8.0.1 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (3)
-
Bulat Ziganshin -
Simon Marlow -
Sven Panne