Fw: Long term support - in general and Windows XP specifically

Howard B. Golden howard_b_golden at yahoo.com
Sat Nov 8 19:32:17 UTC 2014


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 <austin at well-typed.com>
To: "ghc-devs at haskell.org" <ghc-devs at 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


More information about the ghc-devs mailing list