upgrading GHC

[Duncan Coutts]

Bulat,

You mention the problem of having a new version of a library with an
incompatible change appear where a previous version of that library was
included in a platform release.

I think a good model to follow here is GNOME's release model. They do
major releases on a 6-month schedule. Major releases can introduce new
features. For example GNOME 2.20.0 then after each major release they
have a number of minor releases eg 2.20.1, 2.20.2, 2.20.3. These are
exclusively bug fix releases including updated versions of the packages
that were in the original 2.20.0. Those updates are only allowed to fix
bugs, not change any APIs.

The corresponding concept with a Haskell platform release is that every
package is following the package versioning policy and minor/bug-fix
platform releases are only allowed to include updates that are api
compatible.

This is the same way that libraries included with GHC work, that the
library apis should be the same between GHC 6.8.0 and 6.8.2. We have
only very rarely deviated from that policy.

Duncan

On Fri, 2008-02-22 at 17:00 +0300, Bulat Ziganshin wrote:
> 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
>