On Tuesday 16 October 2007 11:45, Claus Reinke wrote: > >> how about using a provides/expects system instead of betting on > >> version numbers? if a package X expects the functionality of base-1.0, > >> cabal would go looking not for packages that happen to share the name, > >> but for packages that provide the functionality. > > > > Using the version number convention mentioned earlier, "base-1.0" > > funcionality is provided by base-1.0.* only. A package can already > > specify that explicitly. > > not entirely correct. you said that major versions implied api changes. > that does not imply that the api is no longer backwards compatible, > only that there are sufficiently substantial new features that a version > naming them seems called for. while base breaks backwards > compatibility, other packages might not do so. > > and cabal does not allow me to specify anything but a name and a > range of numbers as dependencies (there is exposed-modules:, but > no imported-modules:), so i can't say which parts of base-1.0 my > package depends on, and cabal can't decide which versions of > base might be compatible with those more specific dependencies.
I've been giving only cursory attention to this thread so I might have the wrong end of the stick, or indeed the entirely wrong shrub. If the convention for modifying package versions of form x.y.z is: - increment z for bugfixes/changes that don't alter the interface - increment y for changes that consist solely of additions to the interface, parts of the interface may be marked as deprecated - increment x for changes that include removal of deprecated parts of the interface - (optionally) x == 0 => no guarantee and package maintainers are rigorous in following these rules then specifying dependencies as foo-x, foo-x.y, foo-x.y.z should be sufficient. This rigour could largely be enforced by hackage or an automated build system. foo-x is a shortcut for foo-x.0.0 foo-x.y is a shortcut for foo-x.y.0 foo-x.y.z is satisfied by any foo-i.j.k where i=x, j.k>=y.z The 'foo' package name is just an indicator of lineage. foo-2.xxx is not the same package as foo-1.xxx, it's interface is missing something that foo-1.xxx's interface provided. Dependencies of "foo" shouldn't appear in published cabal files. There is a case for their use in development where you are specifying that you want to depend on the very latest version of foo available, perhaps from darcs. When you publish that latest version number gets burned in, eg "foo-2.1.20071016". As for provides/expects and imported-modules instead, isn't that just an arbitrary line drawn in the granularity sand? Perhaps package versions could be expanded to include the type of every function they expose, plus more information to indicate which bugfix version of those functions is present. That's maybe the Right Way... and probably a lot of work. A more convenient place to draw the line seems to be at the package level. > > > I think what you're asking for is more than that: you want us to provide > > base-1.0, base-2.0 and base-3.0 at the same time, so that old packages > > continue to work without needing to be updated. That is possible, but > > much more work for the maintainer. Ultimately when things settle down it > > might make sense to do this kind of thing, but right now I think an > > easier approach is to just fix packages when dependencies change, and to > > identify sets of mutually-compatible packages (we've talked about doing > > this on Hackage before). > > yes. it's called automatic memory management!-) as long as there's > a package X depending on package Y-a.b, package Y-a.b should > not disappear. not having to waste time on such issues is one reason > why programmers are supposed to prefer haskell over non-functional > languages, right?-) I think it's a no-brainer that old versions of packages should remain available for people to use for 'a long time'. If their dependencies are specified properly they should continue building successfully as time passes. Isn't the main problem the use of "foo" dependencies and the resulting version guessing/ambiguity? Presumably it's not usually a problem if indirect package dependencies require incompatible versions of a package. Is this a problem with base because it implicitly has a dependency on a particular version of the GHC internals? Dan _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
