Eternal Compatibility in Theory

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Eternal Compatibility in Theory

Corentin Dupont
Hi Café,
I've read the Eternal Compatibility in Theory article [1], is anyone actually using it?
I don't see it discussed very much on the internet. My biggest concern about it is that it would be a real pollution in the code, because you must import every module with its version number, i.e.

import Data.Maybe_1
instead of
import Data.Maybe

Thus poluting a lot with version numbers, which are not relevant to what the source code should aim at: help the reader understand it.
Secondly, does it means that, as the developper of a package, I have to leave all the previous versions of a module in that package?
I.e: Maybe_1.hs, Maybe_2.hs would have to stay in my package? This seems to be very polluting and redundant.

So the proposition seems to be "versionning and dependency management are a problem, so let's remove the problem by leaving all previous versions in the package".
Did I misunderstood something?

Cheers,
Corentin

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Eternal Compatibility in Theory

Thiago Negri
I don't see anyone using it, and I understand the same as you.

Packages on Hackage should use PVP [1] for versioning.



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe