upgrading GHC

[Bulat Ziganshin]

Hello Duncan,

Friday, February 22, 2008, 2:28:15 AM, you wrote:

> In particular I think we need the infrastructure to keep the time
> required by distro/platform maintainers to a minimum, otherwise it can
> easily turn into a full time job.

> I'd like to see an infrastructure where we can define subsets of hackage
> packages using fully automatic quality tests. Then further subsets
> defined by human review standards and consistent sets of packages that
> are tested together.

Duncan, i like your concrete and detailed plan, but let's see again on
WHAT we want to reach. i think that our goal is two-sided:

1) assemble the GEMS of packages that are guaranteed to work together
2) have some set of "good packages" that meet some quality standards
and therefore recommended for usage

let's consider practical situation. at Oct2007 ghc 6.8 arrives with
LibX 1.0 bundled. authors of other libs started to rewrite their libs
to work with LibX 1.0. then, at Dec2007 LibX 2.0 arrives and then some
libs was upgraded to take advantage of LibX 2.0. they become
incompatible with libs using LibX 1.0 and we got a problem

package versioning policy (i prefer to call it HLP) allows us to watch
over this problem. as far as every library installed define exact
version ranges for its dependencies, it should be easy to determine
that LibY 1.0 and LibZ 1.0 cannot be used together because they relies
on different (and incompatible) versions of LibX


but next goal we want to reach is to PREVENT such situations as much as
possible. and this is social problem. in order to solve it we should
limit freedom of using new library versions by other libraries which
want to be a "good citizens". when ghc 6.8 arrives, all the libraries
bundled with it - with their concrete VERSIONS becomes a base for this
year's HSL (haskell std libs) set. i.e., LibX 1.0 becomes a part of
HSL-2008. LibX 2.0 may arrive next month but this cannot change a
situation - once LibX 1.0 was included in HSL-2008, it stays there

currently, October GHC version is more a testbed and December version is
practical vehicle, so i may propose the following scheme: from Oct to
Dec developers port their libs to new GHC (and HSL!) version, and in
December we "officially" present HSL-2008 as platform for the
practical haskell development of the next year. It's important that
main libs that make up a foundation for application programming are
updated in limited time. say, GUI developers can't upgrade to ghc 6.8
before GUI lib will be ported. so, in Dec2007 we can advertise
HSL-2008 which includes, aside core libs, GUI+DB+Web libs with their
concrete versions/features and this becomes std set of libs for
application developers in 2008 and we can say not "once we had
Streams/Binary/FRP lib but it's lost in times", but "for 2008, we
offer GUI, serialization, DB libs which are really work with current
GHC version"

while it will be great to upgrade main libs before December, it
doesn't mean that HSL-2008 is frozen at this moment. it continues to
grow by accepting new libs and bug-fixed versions of included libs
(keeping the same API). the only thing prohibited is incompatible
versions of the same libs (say, LibX 2.0 if LibX 1.0 is already there)


and here we go to the second goal mentioned at the beginning -
distinguish between high-quality and so-so libs. here we can establish
some set of requirements and check them. we can provide 1-5 stars
system or anything else BUT even if some library completely lacks
docs, doesn't work on windows or even fails unit tests, it still
belongs to the HSL-2008 gem if it works with HSL-2008 libs and there is
no previous incompatible version of this library already included in
HSL-2008. moreover, these conditions may be checked automatically when
uploading package to the Hackage, so library may be nominated
AUTOMATICALLY to a part of HSL-2008 standard (!), although for
practical purposes i think it's better that Hackage just OFFER this
and package author AGREE with it when his package becomes ready to
this honor

This rule doesn't prohibit quick development of libraries and changing
their interfaces every next month. these new versions just will be
considered as "research" ones, with a user's responsibility to
coordinate their versions. i recall Don's phrase "it's easy to use
newer ByteString version, just recompile the base lib" :)


So, hackage should be able to

1) test that uploaded library MAY be included in HSL-20xx gem
2) provide a checkbox to make this decision
3) show for each library to which HSLs it belongs
4) allow to filter libraries list to show libs in specified HSL
5) -.- that are compatible to specified HSL (including libs whose
     checkbox(2) was not checked)

using list(5) is good if you just need to see all libs compatible
with your setup and list(4) provides list of libs which are guaranteed
to compatible with any FUTURE version of given HSL


next, all core libs should obey HLP and have versions >=1.0.
0.xxx version numbers should be left for experiments without any
compatibility guarantees. the same applies to libs on Hackage. i
propose to consider any lib uploaded there which has version >=1.0 and
uses ranges for its dependencies (i.e. have finite lower and
higher bounds) as library obeying HLP

overall, i propose to consider library version as technical field
designed for computers. if any library developer has his own,
non-HLP library versioning policy, he can write these "human versions"
into "description" field. this restriction will allow us to
automatically track version dependencies without adding new
bureaucracy of Cabal fields


two more notes: first, Hackage may check each uploaded library that it
doesn't use the same module names as existing libs and propose to
include it in HSL-xxx only if it doesn't reuse module names of libs
that are already in given HSL

second, HLP doesn't specify whether new library versions may add *new*
modules. if we will allow this, then library functionality may be
extended without losing any bit of compatibility with existing
software

-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com