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
