Hi everyone, We've got a bit of a problem in the community regarding HaXml. This has been brought up before, but never definitively resolved, and it's causing more and more trouble. Over at the HaXml homepage [1], it is stated that 1.13.3 is the most recent stable version of HaXml. I believe that Malcolm Wallace, HaXml maintainer, has confirmed this. Over at the HaXml hackage page [2], it would appear as if 1.19.4 is the most recent stable version of HaXml. There is no provision made to mark some versions as unstable, and to make 1.13.3 the default version downloaded from Hackage. There are API incompatibilities between 1.13.3 and 1.19.4 that make it impossible for my programs to support both. This is becoming a larger and more fragmenting problem. Arch Linux looked at the Hackage package and bundled up 1.19.4. Debian looked at the HaXml website and bundles 1.13.3. So we have a situation where I can write software that builds easily with one or the other, but not both. We really need a fix for this. Some things we could do would be: 1) Make a policy that Hackage is for the "most stable branch" of software only, and remove the 1.19.x series of HaXml. 2) Malcolm could decide to bless 1.19.x as stable, fixing the instant problem, but this would still leave the problem open for the future. 3) Add support to Hackage for labeling branches, and present the stable versions by default. Thoughts? [1] http://www.cs.york.ac.uk/fp/HaXml/ [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HaXml
On Thu, 2008-09-18 at 15:32 -0500, John Goerzen wrote:
Hi everyone,
We've got a bit of a problem in the community regarding HaXml. This has been brought up before, but never definitively resolved, and it's causing more and more trouble.
Over at the HaXml homepage [1], it is stated that 1.13.3 is the most recent stable version of HaXml. I believe that Malcolm Wallace, HaXml maintainer, has confirmed this.
Over at the HaXml hackage page [2], it would appear as if 1.19.4 is the most recent stable version of HaXml. There is no provision made to mark some versions as unstable, and to make 1.13.3 the default version downloaded from Hackage.
But there should be. I have a plan and I intend to implement it. Basically for each package we have an optional suggested version constraint. This would be used in the hackage website to direct people to the 'current' version but most importantly it'd be used by cabal-install and other cabal -> native package conversion tools. It wold be editable on the hackage website by the package author/maintainer and probably other people with the role of managing the hackage collection. Cases like HaXml-1.13 -> 1.19 (or a future stable version) or old-time -> time are also things that the platform might be able to help with in future by managing the transition in a more coherent way rather than what we have now where the transition is rather hap-hazard with half using one and half the other. Duncan
Duncan Coutts wrote:
On Thu, 2008-09-18 at 15:32 -0500, John Goerzen wrote: Basically for each package we have an optional suggested version constraint. This would be used in the hackage website to direct people
That would solve the problem nicely, I think. Do you have an ETA for this feature?
to the 'current' version but most importantly it'd be used by cabal-install and other cabal -> native package conversion tools. It wold be editable on the hackage website by the package author/maintainer and probably other people with the role of managing the hackage collection.
Cases like HaXml-1.13 -> 1.19 (or a future stable version) or old-time -> time are also things that the platform might be able to help with in future by managing the transition in a more coherent way rather than what we have now where the transition is rather hap-hazard with half using one and half the other.
Duncan
In your particular problem there is another way: Ask the distributors to ship both HaXmL versions.. (Most systems will install one only by default (an update supersedes the older one :-( ) But most distributions do let you install two or more versions (?) I think the way to go is beeing able to represent all the work you've done. I'd like to add a pointer to vxml on hackage. But it's still way to unstable for a release. How would branches look like? We no longer have 0.1 0.2 0.5 ... But each version has a set of children and a set of parents (merges) ? So hackage would no longer show other versions: ... ... ... but childs: branchX-0.3 branchY-0.4 branchZ-0.8 parents: .... ? On the other hand the more packages / branches are on hackage the more work packagers have to do.. Marc
Marc Weber wrote:
In your particular problem there is another way: Ask the distributors to ship both HaXmL versions.. (Most systems will install one only by default (an update supersedes the older one :-( ) But most distributions do let you install two or more versions (?)
Yes, most distributions package only one at a time, and yes most could package more than one. Perhaps that would even work with HaXml. BUT: 1) There is still significant end-user confusion 2) This approach doesn't scale once we start thinking of more packages
I think the way to go is beeing able to represent all the work you've done. I'd like to add a pointer to vxml on hackage. But it's still way to unstable for a release.
See, I don't think that Hackage should discourage posting unstable code -- just discourage posting code that is less stable than the previous release. I think there is very little code too unstable for release! Release early, release often. I wrote my first ever Xlib client in C the other day. It's up at git://git.complete.org/ledmon. My first ever patches to xmobar are up at http://darcs.complete.org/xmobar. Don't let unstable scare you off from releasing.
How would branches look like? We no longer have
0.1 0.2 0.5 ...
But each version has a set of children and a set of parents (merges) ?
Simplest way to do this would be to define a boolean flag: "stable" or "unstable". Similarities to Debian here. More complex, you could let authors define branches. The default branch is presented, well, by default. Others are visible. Similarities to Freshmeat here. I don't know that this has to be terribly complex. Just something to get us out of the current situation and prevent it from happening again. -- John
participants (3)
-
Duncan Coutts -
John Goerzen -
Marc Weber