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