Re: [Haskell-cafe] Hackage and HaXml situation

2008-09-19 Thread John Goerzen
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
> 
> 

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Hackage and HaXml situation

2008-09-18 Thread John Goerzen
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


Re: [Haskell-cafe] Hackage and HaXml situation

2008-09-18 Thread Duncan Coutts
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

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] Hackage and HaXml situation

2008-09-18 Thread Marc Weber
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] Hackage and HaXml situation

2008-09-18 Thread John Goerzen
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe