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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe