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