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.

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?

I hope my perspective is of value to the developers.

Regards,

Howard
Northridge, CA, USA



----- Original Message -----
From: Austin Seipp <aus...@well-typed.com>
To: "ghc-devs@haskell.org" <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

Reply via email to