wither the Platform

[Mark Lentczner]

On Fri, Mar 27, 2015 at 5:24 AM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> I'm a bit worried about the aspect of delaying the GHC release schedule
> for the sole purpose to provide the HP with more visibility,


That isn't the purpose at all. My aim ins't to promote HP.
The aim of my suggestion is to ensure that there is a consistent way for
the community to "get Haskell" (as GHC itself is not enough for anyone -
you need cabal at the least, and there are libraries that are common enough
to be considered essential: text, vector, etc...).

It is also to ensure there is a consistent reference point for package
developers to test their packages against, for those packages that wish to
support more than just the current GHC. Again, GHC releases themselves do
not form a big enough reference point to ensure two packages that "support
the last two release" are supporting the same thing.

...

> Otoh,
> there's usually enough time between the last RC and the actual final
> release, which should give the HP at least one week of time anyway w/o
> any active delay on GHC's end.
>

Well - if there is a week of commits to GHC, it should really do another RC
before declaring it final. The difference between the last RC and the
release should a single commit of no more than the version number change
and the change log.

Frankly, if we are all on board with this, then GHC could suffer a few day
(week at most) delay between such an RC (as in "we're frozen, save for the
version stamp"), and announcing "release". This would not only allow there
to be a Platform on the same day - but also GHC bindists for other OSes on
the same day.


> Otoh, as soon as the new HP is released, it provides users with the
> perception of a new stable HP release to jump on right-away. That,
> however, may lead to a poor experience if the it's the first HP release
> for a given major GHC version as Hackage usually hasn't fully caught up
> by the time a GHC x.y.1 is unleashed.


We need to have to maintainers of the packages in the HP on board with this
and down with the "we're all going to gear up in the four weeks before a
GHC version"... not "we'll gear up in the four weeks after". Frankly, for
the kinds of packages that are in the platform (text, vector, unordered
containers, etc...), having these packages lag GHC release so that they are
broken on Hackage the day of GHC release is in nobody's interest: It gives
a poor experience for ALL users of Haskell.

So if we had co-released a HP
> featuring GHC 7.10.1 today, there would still be enough Hackage packages
> not yet compatible with GHC 7.10.1 to recommend users *not* to install
> the release right-away.
>

But that is true of GHC as well. We need to stop having the attitude of
"Platform is for newcomers / GHC is for heavyweights". It is perfectly fine
to announce "GHC 7.10.1 is out - you can install it from Platform 7.10.1
which is a complete installer for your OS with core and standard libraries,
and tools; or if you prefer you can get the minimal binary compiler build.
As always, not all packages on Hackage will be compatible." Then our
recommendations on to users on IRC are about which version is best for
their needs, not "don't install platform, you won't be able to get lens to
compile..."


> So I'm actually not sure if a simultaneous release of GHC x.y.1 w/ HP
> would be in the HP's best interest in terms of providing a reliable and
> complete development environment (which IMO requires access to Hackage,
> even more so if the HP is to be reduced to contain less packages)
>

People who care about stability will go ahead and hang back to what they
consider a stable reference for them. (Gosh, how many projects are still
supporting Python 2.6?!). But it will only be a "stable reference" if
people use it, and package maintainers support it. Today's mess of GHC
releases, Platform releases, alternative installer releases, etc... leaves
both users and package maintainers no way to create or find stability.

- Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150327/66b18a05/attachment.html>