Neil Mitchell wrote:

We're all assuming here that HaXml deliberately decided to change the interface. Is that really true? (only Malcolm can answer)

Yes, it's true. Even a non-Malcolm such as myself can answer this, because of the magnitude of the changes from 1.13 to 1.17. HaXml is somewhere in the process of a big spring cleaning. The real question that only Malcolm can answer is how far through the process of tidying up it is. That bears on whether it's worth bringing haxr up to date; if there's more churn ahead, the answer is probably "not yet".

Neil Mitchell , 2007-02-01 15.59 +0000:

We're all assuming here that HaXml deliberately decided to change the interface. Is that really true? (only Malcolm can answer)

Yes, I had a glance at it and AFAICT he changed the name of the submodule Text.XML.HaXml.Xml2Haskell to something more suitable.

Most of the time I guess that the interface will change by accident, without people spotting. Perhaps we are trying to solve the wrong problem...

You have a point, interface change by accident is a different problem. But it doesn't make the other one wrong. Clearly not all interface change is by accident; see above. But without a way for the author to declare it, we're effectively treating all these instances as change by accident as well, which means more maintenance. -Sven

On Thu, Feb 01, 2007 at 05:29:44PM +0100, Sven Moritz Hallberg wrote:

What's wrong with the solution I proposed, i.e. to add an explicit field to the package description which states whether we broke compatibility or not? It's effectively the same as a version numbering convention without having to tell everyone how to assign their numbers. Don't get me wrong, I'd be all for a consistent numbering scheme. Is everyone else also?

With version numbers, it suffices that each author has a rule of incrementing at a certain level if compatibility is broken. It need not be the same level for different packages (though that would be less confusing). They might have two levels of compatibility: merely adding functions, types or classes will not break any clients that use explicit imports.

Ross Paterson , 2007-02-01 17.45 +0000:

With version numbers, it suffices that each author has a rule of incrementing at a certain level if compatibility is broken. It need not be the same level for different packages (though that would be less confusing).

They might have two levels of compatibility: merely adding functions, types or classes will not break any clients that use explicit imports.

Yes, good point. In fact, I didn't think of the fact that adding functions etc. can also break an importer. :/ It might indeed be a good idea to be able to distinguish these two levels. Already requiring old versions when just an export is added might not offer much benefit to treating all versions incompatible to each other in the first place... Actually, upon pondering the fact that it's impossible to enforce the usage of a particular numbering scheme, it occured to me: We could just make version numbers following the standard scheme (whichever exactly) syntactically distinguishable from the current form. Then cabal-install could work happily with its new information and we don't have to /impose/ a mandatory scheme on everyone. (We could, however, apply some leverage towards "persuading" authors to use the new scheme by emitting a warning from Cabal when it's not used.) Is this a good idea? Suggestions for what "standard-scheme" version numbers could look like? (Coolest look wins!) Regards, Sven

On Sat, 2007-02-03 at 12:37 -0800, Isaac Jones wrote:

The way I propose to solve this version incompatibility problem in the short term is to use the "testing" hackage repository to collect packages that are known to work together. For instance, we could put haxml 1.17 in and only allow things that compile with that version. unstable can still have stuff that only compiles w/ 1.13, but if an author wants their tool to be in "testing", then they have to fix it up to be compatible. (Or we might decide that 1.13 is a better version to have in testing.)

This will encouarage people to update their packages with a collection of dependencies that are somewhat "blessed", even if that blessing is a little arbitrary.

We can ourselves modify packages so that their version dependency is more accurate than upstream knows them to be :)

It's for issues like this (ie creating a distribution) that having the .cabal file outside the .tar.gz file is a bonus. Let me compare to Gentoo: we provide a distribution of Haskell packages that we test as a group and know that they work together. We test stuff and make sure that the dependencies are sufficiently tight so that things don't break on users' systems. We have an .ebuild file for each package. For a haskell package this obviously duplicates most of the information in the .cabal file, however it gives us an opportunity to make slight corrections. The analogy in hackage is that the .cabal file outside the .tar.gz package can serve as the place where the distributors can 'fix' things. One example of this is the "tested-with:" field, another might be changing "build-depends:" to more tightly constrain version numbers. Duncan

On Feb 3, 2007, at 21:37 , Isaac Jones wrote:

The way I propose to solve this version incompatibility problem in the short term is to use the "testing" hackage repository to collect packages that are known to work together. For instance, we could put haxml 1.17 in and only allow things that compile with that version. unstable can still have stuff that only compiles w/ 1.13, but if an author wants their tool to be in "testing", then they have to fix it up to be compatible. (Or we might decide that 1.13 is a better version to have in testing.)

This will encouarage people to update their packages with a collection of dependencies that are somewhat "blessed", even if that blessing is a little arbitrary.

We can ourselves modify packages so that their version dependency is more accurate than upstream knows them to be :)

Is there a way to get that working smoothly with the web interface? I guess we could have a separate web interface installation for each "distribution", but maybe some built-in support could make it nicer to use? /Björn