On Sun, May 13, 2012 at 09:36:40PM +0200, Heinrich Apfelmus wrote:
Joachim Breitner wrote:
Heinrich Apfelmus wrote: [...] I see. Thinking about this, it appears to me that the only way to meet the "one-version-per-package" constraint is the following approach on my part:
A. Always support the latest version of a dependency (compiler, library, ...), i.e. the upper bounds of my version constraints have to match the latest stuff.
B. If desired, support older versions of a dependency by adjusting the lower bounds of my version constraints.
This is exactly what I try to do with the few packages I've written and put on Hackage.
However, this approach is not without problems.
The first problem is this: what happens if the newer version of my [...] version, but doesn't fly with the approach above.
The second problem is that the lower bounds will tend to be higher than necessary. The thing is that once I install the new dependency on my machine and develop a new feature in my package, I can no longer test whether my package still works with the old version. That would require me have both versions of my dependency installed at the same time, which is very tricky with the "one-version-per-package" assumption. Unable to test the old version, I cannot, in good conscience, include a dependency on the old version. (However, doing so is not too bad for me, because I can deflect "the blame" in case it doesn't work.)
Luckily I've never had to deal with the first issue. The second on the other hand I have a rather lazy process for: *I* release packages with the dependencies that I've tested, then I'm happy to accept patches that relax the dependencies downwards (and sometimes upwards, when I'm slow) from users, as long as they claim to have run the test suites. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay