<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 27, 2015 at 5:24 AM, Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvr@gnu.org" target="_blank">hvr@gnu.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm a bit worried about the aspect of delaying the GHC release schedule<br>
for the sole purpose to provide the HP with more visibility,</blockquote><div><br></div><div>That isn't the purpose at all. My aim ins't to promote HP.</div><div>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...).</div><div><br></div><div>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.</div><div><br></div><div>... <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Otoh,<br>
there's usually enough time between the last RC and the actual final<br>
release, which should give the HP at least one week of time anyway w/o<br>
any active delay on GHC's end.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Otoh, as soon as the new HP is released, it provides users with the<br>
perception of a new stable HP release to jump on right-away. That,<br>
however, may lead to a poor experience if the it's the first HP release<br>
for a given major GHC version as Hackage usually hasn't fully caught up<br>
by the time a GHC x.y.1 is unleashed.</blockquote><div><br></div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So if we had co-released a HP<br>
featuring GHC 7.10.1 today, there would still be enough Hackage packages<br>
not yet compatible with GHC 7.10.1 to recommend users *not* to install<br>
the release right-away.<br></blockquote><div><br></div><div>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..."</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I'm actually not sure if a simultaneous release of GHC x.y.1 w/ HP<br>
would be in the HP's best interest in terms of providing a reliable and<br>
complete development environment (which IMO requires access to Hackage,<br>
even more so if the HP is to be reduced to contain less packages)<br></blockquote><div><br></div><div>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.</div><div><br></div><div>- Mark</div></div></div></div>