On 11/08/2014 07:32 PM, Howard B. Golden wrote:

Hi,

I am combining the two topics because the issues are both support-related.

First, long term support (LTS) is an important goal in making GHC/Haskell a viable production platform. I would argue that providing it is a necessary condition to encourage more adoption of Haskell by "plain users" (as opposed to those willing to take more risks). This includes both individuals and organizations. I believe this makes LTS a high priority for the community.

LTS requires support of both GHC and stable libraries. Any plan for LTS must incorporate a plan for identifying libraries to keep supporting for the same period. This must be part of the effort. FP Complete's Stackage is one approach.

Practically, each LTS version requires significant maintainer resources. Therefore, there is a tension between how many versions to support, how long to support them, and how much demand there will be for new features. The developers need to get a sense of how much value the "plain user" will get from a new release versus bug fixes and backports to an LTS release. As a thought experiment (and perhaps a survey of users), how many users are content with GHC 7.4, 7.6 and 7.8, or even earlier releases? Will they clamor for the new features in 7.10, or is this more aimed at those who are experimenting or are willing to take greater risk? What is the current demographic of users/GHC release usage? Based on the results of this study, we'll have a better idea of what release to make the first LTS one. I would suggest starting with a prior release based on what is being used now. For example, find out how many users are using 7.4 and ask what difficulties they would have in adopting 7.6. Try to get a sense of what the first LTS release should be, recognizing that you won't get unanimous agreement.

I am an interested observer, not an active developer, so take my comments with this in mind. I wonder if the release of 7.10 is being rushed. Perhaps once a year releases are too frequent for everyone except the bleeding edge, who may be satisfied with snapshots. Maybe a reallocation of developer effort should be considered. This question deserves to be considered even if it is ultimately discarded.

If organisations care then they should voice their thoughts *and* provide some developer effort to make the backports. Delaying new releases and pulling off volunteers to do soul-crushing fix backporting because it might, just might, make it easier for some business out there to achieve something is silly. No one wants to put their free time into porting stuff years back especially if it might not even matter.

The issue of Windows XP support should be considered using a similar approach. If an LTS release is created with Windows XP support, this should satisfy XP users for a period of time. It could then be discussed when XP support would no longer be part of a later version. I don't know what API differences there are between XP and Vista or Window 7 that impact GHC. Do the newer APIs provide a significant benefit that justifies dropping XP support? Could newer features be used only where essential, so degraded XP support can be maintained longer?

XP came out in 2001. There's LTS and then there's 13 year old OS that's after EOL from its own developer.

I hope my perspective is of value to the developers.

Regards,

Howard Northridge, CA, USA

----- Original Message ----- From: Austin Seipp To: "ghc-devs@haskell.org" Cc:

Sent: Friday, November 7, 2014 2:07 PM Subject: GHC Weekly News - 2014/11/07

[Excerpt] - Austin also opened a discussion about a possible LTS branch for GHC, spawned off from a suggestion by John Lato a few weeks email. This discussion has been brought up several times before this, but for the most part has fizzled out a bit. But maybe with a different focus - on a separate branch with a team of maintainers - we can hash out a plan of action, and just give it a whirl. https://www.haskell.org/pipermail/ghc-devs/2014-November/007207.html - Austin Seipp brought up a question about Windows support: can we officially drop support for XP, now that Microsoft has done the same? And what minimum version requirements should we endorse? Vista or Windows 7 would give improvements due to API improvements, with Windows 7 offering even more. If you're a GHC on Windows user, please let us know! https://www.haskell.org/pipermail/ghc-devs/2014-November/007199.html _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Mateusz K.

On 2014-11-08 at 20:32:17 +0100, Howard B. Golden wrote: [...]

I am an interested observer, not an active developer, so take my comments with this in mind. I wonder if the release of 7.10 is being rushed. Perhaps once a year releases are too frequent for everyone except the bleeding edge, who may be satisfied with snapshots. Maybe a reallocation of developer effort should be considered. This question deserves to be considered even if it is ultimately discarded.

Fyi, last year there was already a discussion sub-thread debating a change of GHC's yearly major release cycle over at http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/23425/focus=234... IIRC, the conclusion was basically that a yearly cycle is a good compromise balancing all needs/wishes involved. IMO, since GHC gains so many new features/improvements every year already, releasing less often would, for one, increase the amount of new (potentially non-backward compatible changes) features contained in a release, therefore increasing the work involved to update old code-bases to a new GHC release[1], while at the same time give less opportunity to get short release-feedback cycles (as Hackage developers probably only take serious proper stable GHC releases (candidates), rather than work-in-progress snapshots that are fast moving targets, potentially exhibiting all sorts of transient bugs). IOW, what I'm basically saying is that I'm a proponent of http://en.wikipedia.org/wiki/Release_early,_release_often [1]: An *extreme* example of what can happen if you accumulate too many changes into a new compiler/language release is the Python3 situation, where it took ages for code-bases to get updated/ported from Python2 to Python3 (and it's still ongoing), as the upgrade path was too steep, while Python3 development was even slowed down for a few years by a self-imposed "Python Language Moratorium" to let Python3's adoption catch up. Cheers, hvr