5 ms·

Announcing LTS Haskell 1.0

131 points by lelf 12y ago

wwkeyboard 12y ago
So what happened to the "avoid success at all costs" motto?
- ehamberg 12y ago
  (S (VP avoid (NP (NP success) (PP at (NP all costs))))) vs (S (VP avoid (NP success) (PP at (NP all costs))))
- cm3 12y ago
  It's actually "avoid success-at-all-costs" as Simon clarified.
- freyrs3 12y ago
  It has two different parsings: avoid (success at all costs) (avoid success) at all costs The first is more apt description of Haskell's design, the later is more of a joke.
  - dguaraglia 12y ago
    One could say that the second parsing is... too eager? :)
mrottenkolber 12y ago
I guess this is similar to Quicklisp for CL packages? A stable "world snapshot" every now and then instead of rolling releases. I works pretty well in the CL world, I think this approach (releases) will become standard for package management in Ecosystem-package-managers (as it has been in the OS world).
- cschneid 12y ago
  Sorta yes. In order of wild-west to stable, it's: Hackage - live packages get uploaded and released fast Stackage - a rolling tested release. It promises that all packages will compile together. (There are a few flavors of this). and now LTS Haskell. A snapshot of Stackage that doesn't roll very quickly (every 3 months). It won't do upgrades to packages at all, except for bug fix & patch releases. So your own application code can pull down the LTS today, and again tomorrow, and be relatively sure that everything will work the same.
ryanmk 12y ago
The website doesn't say what LTS haskell is. A curated set of packages? Of what?
- exDM69 12y ago
  My best understanding from the posting is that it's going to be a "stable" version of the "Haskell Platform" set of packages. Haskell has been notorious for moving (too?) fast while not maintaining decent backwards/forwards compatibility, a problem made worse by some tooling issues ("cabal hell"). Now most of the technical issues should be solved.
  - tibbe 12y ago
    The core set of packages (e.g. those in the platform) tend to not break backwards compatibility, but you're right that there are still packages that move fast and do.
  - tel 12y ago
    As far as I'm aware this has nothing to do with the Haskell Platform and is, in fact, more or less a competitor.
    - dons 12y ago
      It does seem to be a competitor. They could use the same infra to do the HP versioning and builds. Some NIH going on? The key here seems to be the level of automation, which is great to see.
      - tel 12y ago
        Unfortunately, I think it's a bit of a branding thing, too. To most people's eyes the HP is something of a failure since it's so slow to release—never mind the stabilizing effect it has had on all constituent projects. Stackage thus grabbed some market- and mind-share by promising a closer-to-bleeding-edge update path at the cost of lesser stability. From this position they're peeling back a little bit, trading off newness for a bit more stability, in what appears to be the easiest-to-maintain fashion. So from that, it's sort of culturally incompatible with HP, unfortunately. It'd be very nice if some crosscutting could be had once-and-if LTS stabilizes as a product.
MaxGabriel 12y ago
There are a couple questions in the comments about LTS Haskell and related projects, I was thinking this might be a good summary. (tel's might be better, but I had already written this so I'll let others decide https://news.ycombinator.com/item?id=8834823 https://news.ycombinator.com/item?id=8834823) Hackage is the core package server, comparable to RubyGems. The Stackage (http://www.stackage.org/ http://www.stackage.org/) project functions like a CI system for Hackage. Stackage builds and tests the group of packages that have opted in to it, ensuring that the latest versions all work together (when there's an incompatibility between packages, the authors of the packages are pinged to resolve the issue [1]). When a build of all the packages succeeds, Stackage generates a "snapshot", a list of all the package versions used for that build (sort of like a Gemfile.lock/Podfile.lock, for the whole ecosystem). Developers can have Cabal (Haskell build tool) use the package versions from that list when installing new packages. This ensures that when you install a new package that it's compatible with the other packages you're currently using. The issue with those snapshots (generated nightly) is that you'll want to get updates for your packages, but the snapshot generated N days from now might have packages that have made breaking API changes, making them incompatible with your application. LTS Haskell attempts to fix that. It's based off a specific Stackage snapshot. For the duration of the LTS (currently 3 months), the major versions from that snapshot are locked down, but patches/bugfixes will continue to be released. This allows you to get bugfixes for your application while still getting the advantages of Stackage. [1] As an example, when the language-ecmascript 0.17 package was released, the authors of the 2 packages that depended on language-ecmascript < 0.17 were pinged to update their packages: https://github.com/fpco/stackage/issues/390 https://github.com/fpco/stackage/issues/390
namelezz 12y ago
What does LTS stand for? My dirty guess is Love ThreeSome.
- cbd1984 12y ago
  Long Term Support
SideburnsOfDoom 12y ago
"LTS" usually stands for "Long Term Support". This page says "Run weekly point releases" Is this a bizarrely very-rapid software ecosystem where a week is considered "long term". Or am I missing something?
- MaxGabriel 12y ago
  The weekly point releases are bugfixes for that LTS (so 1.1 is just bugfixes for 1.0).
  - SideburnsOfDoom 12y ago
    so "1.1" is the version of the whole thing, even if most of the packages haven't changed; as opposed to the usual way of versioning each package independently? edit yep, looks like it: "an LTS Haskell release reduces it all to a single version number for "my Haskell ecosystem""
  - creichert 12y ago
    In addition to this, the release duration is somewhat experimental. Why such short support windows? The strawmen of three months between releases and a one month grace period are ridiculously short support windows. The reason I propose them is because- like I mentioned in the design goals- we want the smallest delta from how people work today. Right now, there is no concept of stable versions, and we're trying to introduce it. Starting off with a more standard support window of something like two years would be a radical shift in how library users and authors operate today. Three months is very short, but it's long enough for us to test the process. As time goes on, we should have serious community discussions on how long a support window we should have. (I, for one, am fully in favor of extending it well beyond three months.)

131 points by lelf 12y ago

wwkeyboard 12y ago

So what happened to the "avoid success at all costs" motto?

ehamberg 12y ago
(S (VP avoid (NP (NP success) (PP at (NP all costs))))) vs (S (VP avoid (NP success) (PP at (NP all costs))))
cm3 12y ago
It's actually "avoid success-at-all-costs" as Simon clarified.
freyrs3 12y ago
It has two different parsings: avoid (success at all costs) (avoid success) at all costs The first is more apt description of Haskell's design, the later is more of a joke.
- dguaraglia 12y ago
  One could say that the second parsing is... too eager? :)

mrottenkolber 12y ago

I guess this is similar to Quicklisp for CL packages? A stable "world snapshot" every now and then instead of rolling releases. I works pretty well in the CL world, I think this approach (releases) will become standard for package management in Ecosystem-package-managers (as it has been in the OS world).

cschneid 12y ago
Sorta yes. In order of wild-west to stable, it's: Hackage - live packages get uploaded and released fast Stackage - a rolling tested release. It promises that all packages will compile together. (There are a few flavors of this). and now LTS Haskell. A snapshot of Stackage that doesn't roll very quickly (every 3 months). It won't do upgrades to packages at all, except for bug fix & patch releases. So your own application code can pull down the LTS today, and again tomorrow, and be relatively sure that everything will work the same.

ryanmk 12y ago

The website doesn't say what LTS haskell is. A curated set of packages? Of what?

exDM69 12y ago
My best understanding from the posting is that it's going to be a "stable" version of the "Haskell Platform" set of packages. Haskell has been notorious for moving (too?) fast while not maintaining decent backwards/forwards compatibility, a problem made worse by some tooling issues ("cabal hell"). Now most of the technical issues should be solved.
- tibbe 12y ago
  The core set of packages (e.g. those in the platform) tend to not break backwards compatibility, but you're right that there are still packages that move fast and do.
- tel 12y ago
  As far as I'm aware this has nothing to do with the Haskell Platform and is, in fact, more or less a competitor.
  - dons 12y ago
    It does seem to be a competitor. They could use the same infra to do the HP versioning and builds. Some NIH going on? The key here seems to be the level of automation, which is great to see.
    - tel 12y ago
      Unfortunately, I think it's a bit of a branding thing, too. To most people's eyes the HP is something of a failure since it's so slow to release—never mind the stabilizing effect it has had on all constituent projects. Stackage thus grabbed some market- and mind-share by promising a closer-to-bleeding-edge update path at the cost of lesser stability. From this position they're peeling back a little bit, trading off newness for a bit more stability, in what appears to be the easiest-to-maintain fashion. So from that, it's sort of culturally incompatible with HP, unfortunately. It'd be very nice if some crosscutting could be had once-and-if LTS stabilizes as a product.

MaxGabriel 12y ago

There are a couple questions in the comments about LTS Haskell and related projects, I was thinking this might be a good summary. (tel's might be better, but I had already written this so I'll let others decide https://news.ycombinator.com/item?id=8834823 https://news.ycombinator.com/item?id=8834823) Hackage is the core package server, comparable to RubyGems. The Stackage (http://www.stackage.org/ http://www.stackage.org/) project functions like a CI system for Hackage. Stackage builds and tests the group of packages that have opted in to it, ensuring that the latest versions all work together (when there's an incompatibility between packages, the authors of the packages are pinged to resolve the issue [1]). When a build of all the packages succeeds, Stackage generates a "snapshot", a list of all the package versions used for that build (sort of like a Gemfile.lock/Podfile.lock, for the whole ecosystem). Developers can have Cabal (Haskell build tool) use the package versions from that list when installing new packages. This ensures that when you install a new package that it's compatible with the other packages you're currently using. The issue with those snapshots (generated nightly) is that you'll want to get updates for your packages, but the snapshot generated N days from now might have packages that have made breaking API changes, making them incompatible with your application. LTS Haskell attempts to fix that. It's based off a specific Stackage snapshot. For the duration of the LTS (currently 3 months), the major versions from that snapshot are locked down, but patches/bugfixes will continue to be released. This allows you to get bugfixes for your application while still getting the advantages of Stackage. [1] As an example, when the language-ecmascript 0.17 package was released, the authors of the 2 packages that depended on language-ecmascript < 0.17 were pinged to update their packages: https://github.com/fpco/stackage/issues/390 https://github.com/fpco/stackage/issues/390

namelezz 12y ago

What does LTS stand for? My dirty guess is Love ThreeSome.

cbd1984 12y ago
Long Term Support

SideburnsOfDoom 12y ago

"LTS" usually stands for "Long Term Support". This page says "Run weekly point releases" Is this a bizarrely very-rapid software ecosystem where a week is considered "long term". Or am I missing something?

MaxGabriel 12y ago
The weekly point releases are bugfixes for that LTS (so 1.1 is just bugfixes for 1.0).
- SideburnsOfDoom 12y ago
  so "1.1" is the version of the whole thing, even if most of the packages haven't changed; as opposed to the usual way of versioning each package independently? edit yep, looks like it: "an LTS Haskell release reduces it all to a single version number for "my Haskell ecosystem""
- creichert 12y ago
  In addition to this, the release duration is somewhat experimental. Why such short support windows? The strawmen of three months between releases and a one month grace period are ridiculously short support windows. The reason I propose them is because- like I mentioned in the design goals- we want the smallest delta from how people work today. Right now, there is no concept of stable versions, and we're trying to introduce it. Starting off with a more standard support window of something like two years would be a radical shift in how library users and authors operate today. Three months is very short, but it's long enough for us to test the process. As time goes on, we should have serious community discussions on how long a support window we should have. (I, for one, am fully in favor of extending it well beyond three months.)