Re: [Haskell-cafe] versioning of Haskell packages
Rogan Creswick schrieb: We *do* still have some trouble maintaining / enforcing the PVP in general, and there are a few things that it doesn't cover (I don't believe exception behavior is covered, for example, although I'd argue that throwing more exceptions than a previous version introduces a substantial API change. Anyhow, that's a different rant. ;). If exceptions would be part of the type, then adding exceptions would change the API. I would like that very much. We can already have that behaviour with the existing exception handling packages. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] versioning of Haskell packages
On 30.04.2011 5:06, Rogan Creswick wrote: On Fri, Apr 29, 2011 at 3:05 PM, Daniil Elovkov daniil.elov...@gmail.com 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. I think the PVP (Package Versioning Policy) covers a lot of what you're discussing, but I may misunderstand: http://www.haskell.org/haskellwiki/Package_versioning_policy We *do* still have some trouble maintaining / enforcing the PVP in general, and there are a few things that it doesn't cover (I don't believe exception behavior is covered, for example, although I'd argue that throwing more exceptions than a previous version introduces a substantial API change. Anyhow, that's a different rant. ;). Finer granularity would be great -- if it can be done autonomously. I think that raising awareness of the PVP and refining the tools to check for necessary version bumps would be a great step in the right direction. Mmm, thanks for the link, it makes sense. Version numbers that encode whether interface has changed or not. But I would think it's useful to decouple version numbers and specification of compatibility relation, that is not to encode it in versions themselves but sepcify separately. Version numbers are simple things. But compatibilty specification language can become more and more sophisticated with time, versions numbers will immediately become unsuitable for it. You have mentioned exceptions. That's quite an advanced example. But why not. In some very distant future, we may want to be able to say 'This new version is compatible with the previous one but it throws more exceptions'. Or 'the function f has the same interface but has become more strict'. Alright, those 2 examples are a bit too sophisticated maybe. But what I envisioned in the first place is this. In my program/package I specify the fact that I successfully built it with the package X version A.B.C.D.E.F and I don't care about the versioning policies of X. When the package X evolves to any version, as long as the author of X says that it's compatible with the version I used it's safe to use the newer version. The key thing is not trying to predict the future but only telling that I built it with this version and it works. Also I think that fixing A.B digits for package interface may not always be a good idea. If the interface is quite simple and very stable but the implementaion evolves from beta to a finalised high-quality production code, then it would be desirable to reflect the fact in the version. And the last argument in favor of the separate compatibility specification language would be that it should be somewhat easier to force package authors to provide compatibilty information than to follow versioning policy. Compatibilty data would sit in a separate cabal headers/sections and cabal could complain if they are omitted. Of course, the author could write some stubs there and not bother about it. Also, at the bottom of the PVP wiki page there's a link to a blog post 'Eternal compatibility'. I'd think it's quite a radical approach to include every older version of modules in every new release of the package. -- Daniil Elovkov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] versioning of Haskell packages
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? -- Daniil Elovkov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] versioning of Haskell packages
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: mag...@therning.org jabber: mag...@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 pgpUUgdtMLUQc.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] versioning of Haskell packages
On Fri, Apr 29, 2011 at 3:05 PM, Daniil Elovkov daniil.elov...@gmail.com 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. I think the PVP (Package Versioning Policy) covers a lot of what you're discussing, but I may misunderstand: http://www.haskell.org/haskellwiki/Package_versioning_policy We *do* still have some trouble maintaining / enforcing the PVP in general, and there are a few things that it doesn't cover (I don't believe exception behavior is covered, for example, although I'd argue that throwing more exceptions than a previous version introduces a substantial API change. Anyhow, that's a different rant. ;). Finer granularity would be great -- if it can be done autonomously. I think that raising awareness of the PVP and refining the tools to check for necessary version bumps would be a great step in the right direction. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
