[Haskell-cafe] versioning of Haskell packages

Magnus Therning magnus at therning.org
Sat Apr 30 00:11:50 CEST 2011


On Sat, Apr 30, 2011 at 02:05:39AM +0400, Daniil Elovkov wrote:
> Hello list
> 
> I have an idea on versioning of Haskell packages and a small
> question about release model of Haskell Platform. Since the latter
> is shorter let's start with it.
> 
> So, what is the release model of Haskell Platform? Is it released
> every N months and frozen at that point? Or some intermediate
> package/compiler updates can make the new version to appear out of
> schedule?
> 
> Now, about package versioning. Haskell packages are flourishing and
> evolving at a high speed. Packages depend on other package and they
> evolve asynchronously. In result it is easy to end up in need of
> multiple versions of the same package in one program or maybe
> stumble upon other conflicts/problems. I'm expressing myself a
> little vaguely because I don't have a good example in my head right
> now.
> 
> However, the idea is to maintain not just multi-digit version names
> that don't carry any semantics except that 1.1.3 is later than
> 1.1.2, but also somehow describe compatibility between versions.
> 
> This way, even if the package A has jumped from 1.0 to 1.5 and the
> dependent package B has been stagnant all this time (and B depends
> on A 1.0), if we have information that 1.5 is compatible with 1.0,
> then we can safely use A 1.5 while building B. Or we could use
> whatever version of A is found in the system as long as its
> compatible with A 1.0 that B depends on.
> 
> The compatibility relation can be made more fine grained and be
> applied not at the level of packages but that of modules, for
> example. This way, if we only use modules that are compatible with
> the version we depend on, it's fine to go with the newer version.
> Even if the package as a whole is not compatible.
> 
> Also, when doing this at the level of modules, package authors could
> deliberately maintain compatibility by leaving the API of old
> modules intact and making them sort of wrappers to the new API which
> itself is not compatible with the older version.
> 
> Of course, if the case when a newer version is backwards compatible
> is rare for most Haskell packages, then the idea doesn't make a lot
> of sense. But if it's common, then this could simplify building
> packages/programs and maintaining installed packages.
> 
> What do you think?

Why is dependencies expressed as ranges not enough to cover this?

In fact, Cabal allows not only ranges, but also rather more
complicated logical expressions of versions, for dependencies.

/M

-- 
Magnus Therning                      OpenPGP: 0xAB4DFBA4 
email: magnus at therning.org   jabber: magnus at therning.org
twitter: magthe               http://therning.org/magnus


Perl is another example of filling a tiny, short-term need, and then
being a real problem in the longer term.
     -- Alan Kay
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110429/411fcd92/attachment.pgp>


More information about the Haskell-Cafe mailing list