Re: GHC 7.8 release redux
On Thu, Apr 18, 2013 at 12:21:26PM -0400, Ben Gamari wrote: what is the plan for 7.8? Will it admit API breakage? Should we establish a timeframe for getting work in before a formal release candidate is cut? 7.8 will be released as shortly after ICFP as we can. It will allow API changes. There's no hard timeframe yet, but the sooner a patch is sent, the more likely it is to make it in. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
wren ng thornton w...@freegeek.org writes: [...] But again, this depends on how feasible it would be to actually split the packages apart. Is it feasible? Some time last year, I tried to extract the module import inter-dependencies in the base package (with the help of GHC's -ddump-minimal-imports), and came up with the following relations: all-deps.lst Description: Binary data The main problem I see are the cyclic dependencies between groups of modules; e.g. consider the import-deps between the Prelude module and the GHC.* modules: GHC.ConsoleHandler : Prelude GHC.Constants : Prelude GHC.Environment : Prelude GHC.Event : Prelude GHC.Exts : Prelude GHC.Handle : Prelude GHC.IOBase : Prelude GHC.PArr : Prelude GHC.Stack : Prelude GHC.Stats : Prelude Prelude : GHC.Base Prelude : GHC.Enum Prelude : GHC.Err Prelude : GHC.Float Prelude : GHC.Num Prelude : GHC.Real Prelude : GHC.Show Moreover, the GHC.* modules often also import other standard-library modules such as Data.* for the types and helpers. Also, cyclic dependencies between CABAL packages aren't supported afaik... cheers, hvr ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On 13/02/13 07:06, wren ng thornton wrote: On 2/12/13 3:37 AM, Simon Marlow wrote: One reason for the major version bumps is that base is a big conglomeration of modules, ranging from those that hardly ever change (Prelude) to those that change frequently (GHC.*). For example, the new IO manager that is about to get merged in will force a major bump of base, because it changes GHC.Event. The unicode support in the IO library was similar: although it only added to the external APIs that most people use, it also changed stuff inside GHC.* that we expose for a few clients. The solution to this would be to split up base further, but of course doing that is itself a major upheaval. However, having done that, it might be more feasible to have non-API-breaking releases. While it will lead to much wailing and gnashing of teeth in the short term, if it's feasible to break GHC.* off into its own package, then I think we should. The vast majority of base seems quite stable or else is rolling along at a reasonable pace. And yet, every time a new GHC comes out, there's a new wave of fiddling the knobs on cabal files because nothing really changed. On the other hand, GHC.* moves rather quickly. Nevertheless, GHC.* is nice to have around, so we don't want to just hide that churning. The impedance mismatch here suggests that they really should be separate packages. I wonder whether GHC.* should be moved in with ghc-prim, or whether they should remain separate... But again, this depends on how feasible it would be to actually split the packages apart. Is it feasible? So I think we'd need to add another package, call it ghc-base perhaps. The reason is that ghc-prim sits below the integer package (integer-simple or integer-gmp). It's feasible to split base, but to a first approximation what you end up with is base renamed to ghc-base, and then the new base contains just stub modules that re-export stuff from ghc-base. In fact, maybe you want to do it exactly like this for simplicity - all the code goes in ghc-base. There would be some impact on compilation time, as we'd have twice as many interfaces to read. I believe Ian has done some experiments with splitting base further, so he might have more to add here. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Perhaps looking at what base-compat has to offer (*A compatibility layer for base*) is relevant to this discussion. See: https://github.com/sol/base-compat#readme http://hackage.haskell.org/package/base-compat I didn't use it but it looks as promising approach to base API stability. All best, Krzysztof Skrzętnicki On Wed, Feb 13, 2013 at 10:00 AM, Simon Marlow marlo...@gmail.com wrote: On 13/02/13 07:06, wren ng thornton wrote: On 2/12/13 3:37 AM, Simon Marlow wrote: One reason for the major version bumps is that base is a big conglomeration of modules, ranging from those that hardly ever change (Prelude) to those that change frequently (GHC.*). For example, the new IO manager that is about to get merged in will force a major bump of base, because it changes GHC.Event. The unicode support in the IO library was similar: although it only added to the external APIs that most people use, it also changed stuff inside GHC.* that we expose for a few clients. The solution to this would be to split up base further, but of course doing that is itself a major upheaval. However, having done that, it might be more feasible to have non-API-breaking releases. While it will lead to much wailing and gnashing of teeth in the short term, if it's feasible to break GHC.* off into its own package, then I think we should. The vast majority of base seems quite stable or else is rolling along at a reasonable pace. And yet, every time a new GHC comes out, there's a new wave of fiddling the knobs on cabal files because nothing really changed. On the other hand, GHC.* moves rather quickly. Nevertheless, GHC.* is nice to have around, so we don't want to just hide that churning. The impedance mismatch here suggests that they really should be separate packages. I wonder whether GHC.* should be moved in with ghc-prim, or whether they should remain separate... But again, this depends on how feasible it would be to actually split the packages apart. Is it feasible? So I think we'd need to add another package, call it ghc-base perhaps. The reason is that ghc-prim sits below the integer package (integer-simple or integer-gmp). It's feasible to split base, but to a first approximation what you end up with is base renamed to ghc-base, and then the new base contains just stub modules that re-export stuff from ghc-base. In fact, maybe you want to do it exactly like this for simplicity - all the code goes in ghc-base. There would be some impact on compilation time, as we'd have twice as many interfaces to read. I believe Ian has done some experiments with splitting base further, so he might have more to add here. Cheers, Simon __**_ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.**org Glasgow-haskell-users@haskell.org http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-usershttp://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Wed, Feb 13, 2013 at 09:00:15AM +, Simon Marlow wrote: I believe Ian has done some experiments with splitting base further, so he might have more to add here. There are some sensible chunks that can be pulled out, e.g. Foreign.* can be pulled out into a separate package fairly easily IIRC. Part of the problem is that it's hard to see what's possible without actually doing it, because base is so large, and has so many imports and import loops. IMO by far the easiest way to improve base would be to start off by breaking it up into lots of small packages (some of which will probably be single-module packages, others may contain an entire hierarchy like Foreign.*, and others may contain an odd mixture of modules due to dependency problems). Then we can look at which packages ought to be split up, which ought to be coalesced, and which ought to be moved higher up or lower down the dependency tree, and then look at which module imports are preventing what we want to do and see if there's a way to fix them (either by moving a definition and reversing an import, or by changing an import to import something lower down the dependency tree instead). If we go this route, then we would probably want to end up without a package called 'base', and then to make a new package called 'base' that just re-exports modules from all the new packages. I imagine the first release would let people use the new base without warnings, a year later new base would give deprecated warnings, and the following year we'd remove it. We could do this process slower, but the sooner packages move off of base, the sooner they benefit from fewer major version bumps. The advantages would be: * the new packages would be easier to maintain than base is * we could more easily make other improvements we'd like to make, e.g. we could move the unix and Win32 packages further down the tree without having to do it in one big leap, and without having to put them below the whole of base * if one module causes a major version bump, then only libraries using that functionality would need to relax their dependencies, rather than every single package * some targets (JS, JVM, .NET, etc) or other implementations might want to do things like IO, concurrency, etc, completely differently. This way they'd just use a different io/concurrency package, rather than having to have a different implementation of parts of base * it would be nice if pure libraries could simply not depend on the io package etc, and thus clearly do no IO The disadvantage is that, at some point between the first release and the release that removes base, each package will have to have its dependencies updated. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 7.8 release?
I would like to see base split up, but I am reluctant to invest the effort to do it. I'm not going to do it myself, and Ian's time is so precious on many fronts. My guess is that it'll need someone else to take the lead, with advice from HQ. Simon | -Original Message- | From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org] On | Behalf Of Ian Lynagh | Sent: 13 February 2013 13:58 | To: Simon Marlow | Cc: wren ng thornton; glasgow-haskell-users; ghc-d...@haskell.org | Subject: Re: GHC 7.8 release? | | On Wed, Feb 13, 2013 at 09:00:15AM +, Simon Marlow wrote: | | I believe Ian has done some experiments with splitting base further, | so he might have more to add here. | | There are some sensible chunks that can be pulled out, e.g. Foreign.* | can be pulled out into a separate package fairly easily IIRC. | | Part of the problem is that it's hard to see what's possible without | actually doing it, because base is so large, and has so many imports and | import loops. IMO by far the easiest way to improve base would be to | start off by breaking it up into lots of small packages (some of which | will probably be single-module packages, others may contain an entire | hierarchy like Foreign.*, and others may contain an odd mixture of | modules due to dependency problems). | | Then we can look at which packages ought to be split up, which ought to | be coalesced, and which ought to be moved higher up or lower down the | dependency tree, and then look at which module imports are preventing | what we want to do and see if there's a way to fix them (either by | moving a definition and reversing an import, or by changing an import to | import something lower down the dependency tree instead). | | If we go this route, then we would probably want to end up without a | package called 'base', and then to make a new package called 'base' that | just re-exports modules from all the new packages. I imagine the first | release would let people use the new base without warnings, a year later | new base would give deprecated warnings, and the following year we'd | remove it. We could do this process slower, but the sooner packages move | off of base, the sooner they benefit from fewer major version bumps. | | The advantages would be: | * the new packages would be easier to maintain than base is | * we could more easily make other improvements we'd like to make, e.g. |we could move the unix and Win32 packages further down the tree |without having to do it in one big leap, and without having to put |them below the whole of base | * if one module causes a major version bump, then only libraries using |that functionality would need to relax their dependencies, rather than |every single package | * some targets (JS, JVM, .NET, etc) or other implementations might want |to do things like IO, concurrency, etc, completely differently. This |way they'd just use a different io/concurrency package, rather than |having to have a different implementation of parts of base | * it would be nice if pure libraries could simply not depend on the io |package etc, and thus clearly do no IO | | The disadvantage is that, at some point between the first release and | the release that removes base, each package will have to have its | dependencies updated. | | | Thanks | Ian | | | ___ | ghc-devs mailing list | ghc-d...@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On 11/02/13 23:03, Johan Tibell wrote: Hi, I think reducing breakages is not necessarily, and maybe not even primarily, an issue of releases. It's more about realizing that the cost of breaking things (e.g. changing library APIs) has gone up as the Haskell community and ecosystem has grown. We need to be conscious of that and carefully consider if making a breaking change (e.g. changing a function instead of adding a new function) is really necessary. Many platforms (e.g. Java and Python) rarely, if ever, make breaking changes. If you look at compiler projects (e.g. LLVM and GCC) you never see intentional breakages, even in major releases*. Here's a question I think we should be asking ourselves: why is the major version of base bumped with every release? Is it really necessary to make breaking changes this often? One reason for the major version bumps is that base is a big conglomeration of modules, ranging from those that hardly ever change (Prelude) to those that change frequently (GHC.*). For example, the new IO manager that is about to get merged in will force a major bump of base, because it changes GHC.Event. The unicode support in the IO library was similar: although it only added to the external APIs that most people use, it also changed stuff inside GHC.* that we expose for a few clients. The solution to this would be to split up base further, but of course doing that is itself a major upheaval. However, having done that, it might be more feasible to have non-API-breaking releases. Of course we do also make well-intentioned changes to libraries, via the library proposal process, and some of these break APIs. But it wouldn't do any harm to batch these up and defer them until the next API-changing release. It would be great to have a list of the changes that had gone into base in the last few major releases, any volunteers? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On 02/12/2013 09:37 AM, Simon Marlow wrote: On 11/02/13 23:03, Johan Tibell wrote: Hi, Of course we do also make well-intentioned changes to libraries, via the library proposal process, and some of these break APIs. But it wouldn't do any harm to batch these up and defer them until the next API-changing release. Indeed. It might even be preferable to just have one huge breakage every year than having lots of minor breakages which require updating packages (and dependencies). At least you'll feel you're getting your money's worth. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On 2/12/13 3:37 AM, Simon Marlow wrote: One reason for the major version bumps is that base is a big conglomeration of modules, ranging from those that hardly ever change (Prelude) to those that change frequently (GHC.*). For example, the new IO manager that is about to get merged in will force a major bump of base, because it changes GHC.Event. The unicode support in the IO library was similar: although it only added to the external APIs that most people use, it also changed stuff inside GHC.* that we expose for a few clients. The solution to this would be to split up base further, but of course doing that is itself a major upheaval. However, having done that, it might be more feasible to have non-API-breaking releases. While it will lead to much wailing and gnashing of teeth in the short term, if it's feasible to break GHC.* off into its own package, then I think we should. The vast majority of base seems quite stable or else is rolling along at a reasonable pace. And yet, every time a new GHC comes out, there's a new wave of fiddling the knobs on cabal files because nothing really changed. On the other hand, GHC.* moves rather quickly. Nevertheless, GHC.* is nice to have around, so we don't want to just hide that churning. The impedance mismatch here suggests that they really should be separate packages. I wonder whether GHC.* should be moved in with ghc-prim, or whether they should remain separate... But again, this depends on how feasible it would be to actually split the packages apart. Is it feasible? -- Live well, ~wren ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Hi, one remedy to the problem could be better infrastructure: * More automated test-building of packages on hackage (including test suites) with various GHC releases, and better display of the results. This way, library authors would not have to manually build their library to see if they work with the latest compiler. * Automatic test building of packages with explicit relaxation of the dependencies, to suggest dependency relaxation that would work without code changes (from my work at Debian, in most cases only meta-data changes are required to support newer versions of dependencies, including core libs). * A more liberal attitude to changing other peoples packages’s metadata to fix the dependencies – either to exclude broken combinations or to expand the range. Preferably online, similar to the edit button in github, and checked by the above CI infrastructure. This way, it would be easier for libraries to support newer GHC releases without having to give up supporting older releases. But I know that development of Hackage is not something that seems to be happening a lot right now, and as I don’t help, I’m not complaining. So consider this a side notice and carry on discussing :-) Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 2:46 AM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, one remedy to the problem could be better infrastructure: * More automated test-building of packages on hackage (including test suites) with various GHC releases, and better display of the results. This way, library authors would not have to manually build their library to see if they work with the latest compiler. * Automatic test building of packages with explicit relaxation of the dependencies, to suggest dependency relaxation that would work without code changes (from my work at Debian, in most cases only meta-data changes are required to support newer versions of dependencies, including core libs). * A more liberal attitude to changing other peoples packages’s metadata to fix the dependencies – either to exclude broken combinations or to expand the range. Preferably online, similar to the edit button in github, and checked by the above CI infrastructure. This way, it would be easier for libraries to support newer GHC releases without having to give up supporting older releases. But I know that development of Hackage is not something that seems to be happening a lot right now, and as I don’t help, I’m not complaining. So consider this a side notice and carry on discussing :-) Greetings, Joachim The issue is largely social problem that I suspect technological solutions won't solve. Yes, it would be nice to have better infrastructure. However, at the end of the day, when the automated tests say an API or ABI set has been broken, a non-technical decision needs to be taken (should it be part of the next release, or should it be delayed or removed?) And you will be back to square one. Part of the problem is what happens to successful programming languages: you get users, and users -- believe it or not -- like stability (few people like fiddling with function names and arguments in an otherwise working program or library) and, yes they will take new improvements as long as their working programs continue working. Researchers on the other hand need room to experiment with ideas; they need to get their implementations in the wild to get a sense of what scales, what doesn't. These facts are in tension; you can't solve it by more automated testing. If you want GHC to compete with GCC or Clang, then you know what to do: stop experimenting with the language. So far, most of the work on GHC has been done by researchers who are not paid to do development work -- unless academia changes its standards... -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 10:09:56AM +0800, John Lato wrote: What I would like to see are more patch-level bugfix releases. I suspect the reason we don't have more is that making a release is a lot of work. So, Ian, what needs to happen to make more frequent patch releases feasible? Well, * actually making a release takes time * I assume that you also want more patches merged from the HEAD, rather than just putting intermediate releases out, in which case merging those patches also takes time. And most of the small fixes already get merged, so you'd be looking at merging bigger changes which are more likely to require resolving conflicts, and so take even more time so basically to make more releases we'd need to spend less time doing other stuff (or for someone else to look after the branch). Bigger changes, and especially changes that need altering for the stable branch, are also more likely to introduce bugs. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Sun, Feb 10, 2013 at 3:30 PM, Simon Peyton-Jones simo...@microsoft.com wrote: | You may ask what use is a GHC release that doesn't cause a wave of updates? | And hence that doesn't work with at least some libraries. Well, it's a very useful | forcing function to get new features actually out and tested. | | But the way you test new features is to write programs that use them, | and programs depend on libraries. That is of course ideal, but the ideal carries costs. A half way house is a release whose library support will be patchy. Not such good testing, but much lower costs. But still (I think) a lot more testing than compile HEAD gives us. Simon Fitting: http://xkcd.com/1172/ (sorry, I couldn't resist) -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 7.8 release?
(a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. These must be social questions (what I was earlier calling “signposting”) rather than technical ones. For example, you say that (b) is not subject to any variety of reason, and yet no linux distribution tracks HEAD, does it? They don’t openly insult anyone who points to a release just because HEAD has new cool stuff! No, they track things we call “releases”. Very well, maybe we should call them “previews” instead, and only dignify it as a “release” when, and only when a preview is picked by HP as worthy of incorporation in the next HP. Or something. I’m just looking for a way to reconcile ·Release early, release often ·Stability for the Haskell Platform It seems to me that such a reconciliation is within reach, and is actually very close to what we do, if we only signpost what is what far more vigorously and clearly than we do now. But maybe I’m wrong. Simon From: Brandon Allbery [mailto:allber...@gmail.com] Sent: 11 February 2013 01:15 To: Simon Peyton-Jones Cc: Simon Marlow; Mark Lentczner; Manuel M T Chakravarty; kosti...@gmail.com; glasgow-haskell-users; ghc-d...@haskell.org; Edsko de Vries Subject: Re: GHC 7.8 release? On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: What causes the wave of package updates? Just because GHC 7.8 (say) comes out, no package author need lift a finger. The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates. Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP. (a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. You *might* be able to control expectations with respect to (a); (b) is not subject to any variety of reason. It will produce as much pressure as it has users, plus multiply that pressure by the number of package authors who are also users. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.commailto:allber...@gmail.com ballb...@sinenomine.netmailto:ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Hi, Am Montag, den 11.02.2013, 22:31 + schrieb Simon Peyton-Jones: No, they track things we call “releases”. Very well, maybe we should call them “previews” instead, and only dignify it as a “release” when, and only when a preview is picked by HP as worthy of incorporation in the next HP. wording does indeed help a lot. I remember that 7.2 was dubbed a technology review with the effect that, at least Debian, never included it in the main repository. It was packaged and provided in experimental, for easy access to those who want to play with it, but not with additional library packages. From what I can remember, there was no push towards supporting 7.2 properly, and I believe this would have been different if 7.2 was just “the next regular GHC release”. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Agreed. having relatively bug free technology preview releases, which (perhaps ideally) have new functionality included in a way that keeps the breakage overhead lowish, on a regular basis, is ideal. one thought on the api hacking front: the main concern we're hitting is that we want to not pin internal GHC apis, yet we want to make the breakage rate on libraries people may want to use that might depend on say GHC.Prim or GHC.TH to be minimal. Is a possible solution that on preview releases we have the changed bits of API for a module M to be exported in a module M.Experimental? eg, new ghc primops in a tech preview release maybe are exported by GHC.Prim.Experimental (or something of this sort?) just throwing out one possible point in the design space. cheers -Carter On Mon, Feb 11, 2013 at 5:31 PM, Simon Peyton-Jones simo...@microsoft.comwrote: (a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. ** ** These must be *social* questions (what I was earlier calling “signposting”) rather than technical ones. For example, you say that (b) is not subject to any variety of reason, and yet no linux distribution tracks HEAD, does it? They don’t openly insult anyone who points to a release just because HEAD has new cool stuff! No, they track things we call “releases”. Very well, maybe we should call them “previews” instead, and only dignify it as a “release” when, and only when a preview is picked by HP as worthy of incorporation in the next HP. ** ** Or something. I’m just looking for a way to reconcile **·**Release early, release often **·**Stability for the Haskell Platform It seems to me that such a reconciliation is within reach, and is actually very close to what we do, if we only signpost what is what far more vigorously and clearly than we do now. But maybe I’m wrong. ** ** Simon ** ** *From:* Brandon Allbery [mailto:allber...@gmail.com] *Sent:* 11 February 2013 01:15 *To:* Simon Peyton-Jones *Cc:* Simon Marlow; Mark Lentczner; Manuel M T Chakravarty; kosti...@gmail.com; glasgow-haskell-users; ghc-d...@haskell.org; Edsko de Vries *Subject:* Re: GHC 7.8 release? ** ** On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones simo...@microsoft.com wrote: What causes the wave of package updates? Just because GHC 7.8 (say) comes out, no package author need lift a finger. The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates. Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP. ** ** (a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. ** ** You *might* be able to control expectations with respect to (a); (b) is not subject to any variety of reason. It will produce as much pressure as it has users, plus multiply that pressure by the number of package authors who are also users. ** ** -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Hi, I think reducing breakages is not necessarily, and maybe not even primarily, an issue of releases. It's more about realizing that the cost of breaking things (e.g. changing library APIs) has gone up as the Haskell community and ecosystem has grown. We need to be conscious of that and carefully consider if making a breaking change (e.g. changing a function instead of adding a new function) is really necessary. Many platforms (e.g. Java and Python) rarely, if ever, make breaking changes. If you look at compiler projects (e.g. LLVM and GCC) you never see intentional breakages, even in major releases*. Here's a question I think we should be asking ourselves: why is the major version of base bumped with every release? Is it really necessary to make breaking changes this often? How about aiming for having GHC 7.10 be a release where we only add new stuff and improve old stuff? -- Johan * A major GCC release usually signifies that some large change to the code generator was made. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, 11 Feb 2013 15:03:25 -0800 Johan Tibell johan.tib...@gmail.com wrote: Many platforms (e.g. Java and Python) rarely, if ever, make breaking changes. If you look at compiler projects (e.g. LLVM and GCC) you never see intentional breakages, even in major releases*. Those are very mature platforms, hundreds of millions of people use them indirectly each day, it's hard to compare GHC to them. If anything, Haskell is very young for its age, and should rather move faster. Bad mistakes, accidents and partial or inefficient implementations proliferate in standard libraries for decades, tampering GHC's growth as a serious production language. On Mon, 11 Feb 2013 22:31:53 + Simon Peyton-Jones simo...@microsoft.com wrote: no linux distribution tracks HEAD, does it? Gentoo packages HEAD just fine. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 5:03 PM, Johan Tibell johan.tib...@gmail.com wrote: Hi, I think reducing breakages is not necessarily, and maybe not even primarily, an issue of releases. It's more about realizing that the cost of breaking things (e.g. changing library APIs) has gone up as the Haskell community and ecosystem has grown. We need to be conscious of that and carefully consider if making a breaking change (e.g. changing a function instead of adding a new function) is really necessary. Many platforms (e.g. Java and Python) rarely, if ever, make breaking changes. If you look at compiler projects (e.g. LLVM and GCC) you never see intentional breakages, even in major releases*. Here's a question I think we should be asking ourselves: why is the major version of base bumped with every release? Is it really necessary to make breaking changes this often? How about aiming for having GHC 7.10 be a release where we only add new stuff and improve old stuff? -- Johan * A major GCC release usually signifies that some large change to the code generator was made. I have some experience with GCC releases -- having served as a GCC Release Manager for several years. In fact, the release scheme we currently have has gone through several iterations -- usually after many existential crisis. Yes, we don't break GCC ABI lightly, mostly because GCC isn't a research compiler and most research works are done on forgotten branches that nobody cares about anymore. Implementing new standards (e.g. moving from C++03 to C++11 that has several mandated API and ABI breakage) is a royal pain that isn't worth replicating in GHC -- at least if you want GHC to remain a research compiler. Concerning your question about release number, I would venture that there is a certain marketing aspect to it. I can tell you that we, the GCC community, are very poor at that -- otherwise, we would have been at version 26 or something :-) -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 4:34 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: I have some experience with GCC releases -- having served as a GCC Release Manager for several years. In fact, the release scheme we currently have has gone through several iterations -- usually after many existential crisis. Yes, we don't break GCC ABI lightly, mostly because GCC isn't a research compiler and most research works are done on forgotten branches that nobody cares about anymore. Implementing new standards (e.g. moving from C++03 to C++11 that has several mandated API and ABI breakage) is a royal pain that isn't worth replicating in GHC -- at least if you want GHC to remain a research compiler. Concerning your question about release number, I would venture that there is a certain marketing aspect to it. I can tell you that we, the GCC community, are very poor at that -- otherwise, we would have been at version 26 or something :-) Thanks for sharing! My perspective is of course as a user. I don't think I've ever run into a case where the compiler broken a previous work e.g. C++ program. On the other hand I have to make a release of most of the libraries I maintain with every GHC release (to bump cabal version constraints to accept the new base version, if nothing else). -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 6:37 PM, Johan Tibell johan.tib...@gmail.com wrote: On Mon, Feb 11, 2013 at 4:34 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: I have some experience with GCC releases -- having served as a GCC Release Manager for several years. In fact, the release scheme we currently have has gone through several iterations -- usually after many existential crisis. Yes, we don't break GCC ABI lightly, mostly because GCC isn't a research compiler and most research works are done on forgotten branches that nobody cares about anymore. Implementing new standards (e.g. moving from C++03 to C++11 that has several mandated API and ABI breakage) is a royal pain that isn't worth replicating in GHC -- at least if you want GHC to remain a research compiler. Concerning your question about release number, I would venture that there is a certain marketing aspect to it. I can tell you that we, the GCC community, are very poor at that -- otherwise, we would have been at version 26 or something :-) Thanks for sharing! My perspective is of course as a user. I don't think I've ever run into a case where the compiler broken a previous work e.g. C++ program. On the other hand I have to make a release of most of the libraries I maintain with every GHC release (to bump cabal version constraints to accept the new base version, if nothing else). -- Johan I understand. Concerning GCC, it is true that the shear size of the user base and the audience of the compiler (industrial strength) calls for a very conservative approach to ABI or API breaking. On the hand, that means that there are certain welcomed, beneficial changes that we cannot effect. For example, because libstdc++ has been an early adopter of a reference counted-based implementation of std::string, we could not switch to more efficient and more multithread-friendly implementation. That was has been contributed for years but has been sequestered in some branches and namespaces integrated with the rest of the library. That is a shame, but one that is unavoidable given the expectation of the GCC audience. It is not clear to me that GHC is ready for that kind of constraints. We are still describing the C++11 implementation as experimental because we fear that doing otherwise might commit ourselves to an ABI and API that we may need to break later -- possibly because of undetected bugs or because we have found implementations we like better. Of course, that causes some distress in the community because people would like to say GCC implements C++11. Finally, we do break API, you have just been lucky :-) http://gcc.gnu.org/onlinedocs/libstdc++/manual/api.html But, we have also developed very elaborate scheme for symbol versioning and namespace associations to help users digest API breakages without tears. Symbol versioning is a very messy business. I am still of the opinion that the current issue with GHC and HP is social, and it can be resolved through communication and coordination between the two communities for the great good of the Haskell community. -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Let me strongly support Gaby's many points. Simon has it right: we need a way to support 'users' in a stable way, without adding enormous inertia to the development of GHC. I has lived through the slow death of a system from being rapidly innovative to having 'innovations' which exist only because a marketer says that the raft of boring, incremental improvements in each new release are innovative on some What's New blurb. Haskell is extremely useful, and GHC's flavour of Haskell is quite exciting because of the continual evolution of the language. Please don't kill the excitement! The Platform does seem to be an ideal mechanism to provide stability for users who value stability over bleeding-edge. But for that to be successful, there are to be strong community commitment [especially from library maintainers] to tracking that evolution. If the social mechanisms are not strong enough to fully support the Platform, I would say that that is the most important thing to fix. Jacques ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Mon, Feb 11, 2013 at 7:37 PM, Johan Tibell johan.tib...@gmail.comwrote: Thanks for sharing! My perspective is of course as a user. I don't think I've ever run into a case where the compiler broken a previous work e.g. C++ program. On the other hand I have to make a release of most of the libraries I maintain with every GHC release (to bump cabal version constraints to accept the new base version, if nothing else). gcc has had its moments occasionally, although usually major gcc issues aren't called by gcc itself but by packagers (gcc 2.96, anyone?) or fugly politics (egcs). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Simon Peyton-Jones simo...@microsoft.com: | You may ask what use is a GHC release that doesn't cause a wave of updates? | And hence that doesn't work with at least some libraries. Well, it's a very useful | forcing function to get new features actually out and tested. | | But the way you test new features is to write programs that use them, | and programs depend on libraries. That is of course ideal, but the ideal carries costs. A half way house is a release whose library support will be patchy. Not such good testing, but much lower costs. But still (I think) a lot more testing than compile HEAD gives us. I don't think so. In my experience, library support is not patchy, but virtually non-existent as some of the very widely used libraries (like Text) break, and everything else depends on them in one way or another. If we don't make sure that the commonly used libraries work with these preview releases, I don't think those releases are worth the effort. I understand that we can't really guarantee API backwards compatibility for the GHC API (but that's ok as few packages depend on that). Critical are all the libraries bundled with GHC. Adding to them is fine, but no API definitions should change or be removed. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Simon Peyton-Jones simo...@microsoft.com: If there's a path to having a release strategy as Manuel suggests, and having an intermediate release with the new vector primops, type extensions and such goodness, then I'm all for it. A lot of these bits are things ill start using almost immediately in production / real software, esp if I'm not needing to patch every stable library beyond maybe relaxing versioning constraints. Let me suggest once more a possible path, along the lines you suggest ·For people who value stability: use the Haskell Platform. Ignore GHC releases. ·For people who want as many features as possible: use GHC releases. ·For people who want to live on the bleeding edge: build HEAD from source The Haskell Platform decides which GHC release to use, advertises that to package authors who do whatever updates are needed. HP may perfectly sensibly skip an entire release entirely. In short, I think we already have the situation that you desire. Perhaps we just need to market it better? Or am I mistaken? There is one kink: for GHC releases to be *useful* substitutes for the HP for people who want medium stability, they must not change (expect maybe add to) the APIs in GHC versions that do not coincide with HP releases. Why? If they change APIs, many of the packages on Hackage will not build with these intermediate GHC releases, which makes them useless for anything, but testing GHC. Otherwise, I am perfectly happy with your suggestion. However, this is not the status quo. All (major) GHC releases do break critical packages on Hackage. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Simon Marlow marlo...@gmail.com: I agree too - I think it would be great to have non-API-breaking releases with new features. So let's think about how that could work. Some features add APIs, e.g. SIMD adds new primops. So we have to define non-API-breaking as a minor version bump in the PVP sense; that is, you can add to an API but not change it. As a straw man, let's suppose we want to do annual API releases in September, with intermediate non-API releases in February. Both would be classed as major, and bump the GHC major version, but the Feb releases would only be allowed to bump minor versions of packages. (except perhaps the version of the GHC package, which is impossible to keep stable if we change the compiler). So how to manage the repos. We could have three branches, but that doesn't seem practical. Probably the best way forward is to develop new features on separate branches and merge them into master at the appropriate time - i.e. API-breaking feature branches could only be merged in after the Feb release. Thoughts? That sounds sensible to me. Related to this, then, is the management of branches, which, I think, we can improve in two ways: (1) Make all library packages into submodules. (2) Fork-instead-of-branch and use GitHub pull requests. Re (1): submodules make tracking of synchronised branches across multiple repos simpler. Yes, they also have their pitfalls, but given that we are already using submodules extensively, we need to deal with those pitfalls anyway. So, why not reap the benefits, too? Re (2): we should encourage contributors to fork the GHC repos on GitHub and work in those. That makes it easy for everybody to build forks (which will be longer-lived under the above policy) and creating a fork doesn't require any special privileges in GHC repos. Finally, we can use GitHub pull requests to track contributions that are pending integration. This is IMHO also much nicer than attaching patches at Trac tickets. Manuel On 09/02/13 02:04, Manuel M T Chakravarty wrote: I completely agree with Johan. The problem is to change core APIs too fast. Adding, say, SIMD instructions or having a new type extension (that needs to be explicitly activated with a -X option) shouldn't break packages. I'm all for restricting major API changes to once a year, but why can't we have multiple updates to the code generator per year or generally release that don't affect a large number of packages on Hackage? Manuel Johan Tibell johan.tib...@gmail.com mailto:johan.tib...@gmail.com: On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: For a while we've been doing one major release per year, and 1-2 minor releases. We have a big sign at the top of the download page directing people to the platform. We arrived here after various discussions in the past - there were always a group of people that wanted stability, and a roughly equally vocal group of people who wanted the latest bits. So we settled on one API-breaking change per year as a compromise. Since then, the number of packages has ballooned, and there's a new factor in the equation: the cost to the ecosystem of an API-breaking release of GHC. All that updating of packages collectively costs the community a lot of time, for little benefit. Lots of package updates contributes to Cabal Hell. The package updates need to happen before the platform picks up the GHC release, so that when it goes into the platform, the packages are ready. So I think, if anything, there's pressure to have fewer major releases of GHC. However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months. We're getting too efficient at making releases! I think we want to decouple GHC major releases (as in, we did lots of work) from API breaking releases. For example, GCC has lots of major (or big) releases, but rarely, if ever, break programs. I'd be delighted to see a release once in a while that made my programs faster/smaller/buggy without breaking any of them. -- Johan -- You received this message because you are subscribed to the Google Groups parallel-haskell group. To unsubscribe from this group and stop receiving emails from it, send an email to parallel-haskell+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Although it will definitely solve all problems, it would help if hackage would automatically send out mails to maintainers of packages which do not compile with specific ghc versions. I have ran a couple of time into the situation where new GHC releases did nor compile my packages anymore, and I only found out by this being pointed out to me. I do not go over the hackage pages of my packages on a daily basis. The changes I had to make were usually minor, and fixing the problems was easy (except for the case where I had to a add a complicated local type, when let bindings were no longer polymorphic), Doaitse On Feb 10, 2013, at 10:50 , Manuel M T Chakravarty c...@cse.unsw.edu.au wrote: Simon Peyton-Jones simo...@microsoft.com: If there's a path to having a release strategy as Manuel suggests, and having an intermediate release with the new vector primops, type extensions and such goodness, then I'm all for it. A lot of these bits are things ill start using almost immediately in production / real software, esp if I'm not needing to patch every stable library beyond maybe relaxing versioning constraints. Let me suggest once more a possible path, along the lines you suggest ·For people who value stability: use the Haskell Platform. Ignore GHC releases. ·For people who want as many features as possible: use GHC releases. ·For people who want to live on the bleeding edge: build HEAD from source The Haskell Platform decides which GHC release to use, advertises that to package authors who do whatever updates are needed. HP may perfectly sensibly skip an entire release entirely. In short, I think we already have the situation that you desire. Perhaps we just need to market it better? Or am I mistaken? There is one kink: for GHC releases to be *useful* substitutes for the HP for people who want medium stability, they must not change (expect maybe add to) the APIs in GHC versions that do not coincide with HP releases. Why? If they change APIs, many of the packages on Hackage will not build with these intermediate GHC releases, which makes them useless for anything, but testing GHC. Otherwise, I am perfectly happy with your suggestion. However, this is not the status quo. All (major) GHC releases do break critical packages on Hackage. Manuel -- You received this message because you are subscribed to the Google Groups parallel-haskell group. To unsubscribe from this group and stop receiving emails from it, send an email to parallel-haskell+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
* Manuel M T Chakravarty c...@cse.unsw.edu.au [2013-02-10 21:17:07+1100] Re (2): we should encourage contributors to fork the GHC repos on GitHub and work in those. That makes it easy for everybody to build forks (which will be longer-lived under the above policy) and creating a fork doesn't require any special privileges in GHC repos. Finally, we can use GitHub pull requests to track contributions that are pending integration. This is IMHO also much nicer than attaching patches at Trac tickets. FYI, it is also possible to create pull requests from one branch to another. So, for people who already have push-access to the main repo it is not strictly necessary to fork in order to submit a pull request. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 7.8 release?
We seem to be circling ever closer to consensus here! Yay! Indeed! Good :-) However, I’m not getting the bit about API changing vs non-API changing. Firstly I don’t know which APIs are intended. The GHC API is essentially GHC itself, so it changes daily. Maybe you mean the base package? Or what? I suspect you mean that a “non-API-changing” release absolutely guarantees to compile any package that compiled with the previous version. If so, that is a very strong constraint indeed. We do observe it for patch releases for GHC (e g 7.6.2 should compile anything that 7.6.1 compiles). But I think it would be difficult to guarantee for anything beyond a patch release. Every single commit (and the commit rate is many/day) would have to be evaluated against this criterion. And if it failed the criterion, it would have to go on a API-breaking HEAD. In effect we’d have two HEADs. I can’t see us sustaining this. And I don’t yet really see why it’s necessary. If you don’t want an API-breaking change, stick with the patch releases. So, we have a channel for non-API-breaking changes already: the patch releases. So that means we already have all three channels! ·Haskell Platform ·Patch-level releases ·New releases if that’s so, all we need is better signposting. And I’m all for that! Have I got this right? Simon From: Mark Lentczner [mailto:mark.lentcz...@gmail.com] Sent: 09 February 2013 17:48 To: Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon Peyton-Jones; Mark Lentczner; andreas.voel...@gmail.com; Carter Schonwald; kosti...@gmail.com; Edsko de Vries; ghc-d...@haskell.org; glasgow-haskell-users Subject: Re: GHC 7.8 release? We seem to be circling ever closer to consensus here! Yay! I think the distinction of non-API breaking and API breaking release is very important. Refining SPJ's trifecta: Haskell Platform comes out twice a year. It is based on very stable version of GHC, and intention is that people can just assume things on Hackage work with it. These are named for the year and sequence of the release: 2013.2, 2013.2.1, 2013.4,... Non-API breaking releases can come out as often as desired. However, the version that is current as of mid-Feb. and mid-Aug. will be the ones considered for HP inclusion. By non-API breaking we mean the whole API surface including all the libraries bundled with GHC, as well as the operation of ghc, cabal, ghc-pkg, etc. Additions of features that must be explicitly enabled are okay. Additions of new APIs into existing modules are discouraged: Much code often imports base modules wholesale, and name clashes could easily result. These should never bump the major revision number: 7.4.1, 7.4.2... API breaking releases happen by being released into a separate channel when ready for library owners to look at them. This channel should probably go through several stages: Ready for core package owners to work with, then HP package owners, then all package owners. I'd imagine this is a several month process. At the end of which, the release can go into the main channel. Such a merge shouldn't happen more than once a year... I think even once every two years is fine (!) To avoid confusion, I'd suggest that while in the separate channel, these release be named with odd number: 7.9, 7.11,..., and when moved to the main channel renamed to even: 7.10, 7.12... This idea of three channels needs to be much more clearly communicated. The warning on the download page is a failure: Googling ghc takes you to the home page of GHC which immediately trumpets the Lastest News of a release of GHC 7.6.2. Once a user has read that and decided to download, then STOP! box is a) going to be skipped as they scan for the download link, and b) if read and followed, causes the WTF? Why is HP so back rev? So we need to change the front page so that the three channels are clearly communicated and targeted at the right users. - Mark (BTW: The first few links on the GHC web site are out of date: The second nav link is to a survey that is 7 years old. The License page is 8 years out of date. The FAQ is over a year old.) On Sat, Feb 9, 2013 at 8:24 AM, Ian Lynagh i...@well-typed.commailto:i...@well-typed.com wrote: On Sat, Feb 09, 2013 at 12:06:12PM +, Simon Marlow wrote: As a straw man, let's suppose we want to do annual API releases in September, with intermediate non-API releases in February. That's a non-API release 5 months after the API release. 6.10.2 was 5 months after 6.10.1 (.3 was 1 month later, .4 a further 2) 6.12.2 was 4 months after 6.12.1 (.3 was 2 months later) 7.0.2 was 3.5 months after 7.0.1 (.3 was 1 month later, .4 a further 3) 7.2.2 was 3 months after 7.2.1 7.4.2 was 4 months after 7.4.1 7.6.2 was 4.5 months after 7.6.2 so if we do non-API releases, then perhaps it would make sense to stop doing minor releases (unless a release turns out to just be broken). Thanks Ian
RE: GHC 7.8 release?
, even a point release (7.6.2 vs. 7.6.1) of ghc tends to be moderately violent with respect to the Platform. Ideally, such a point release should not be difficult to slot in because it should be compatible modulo bug fixes, but with ghc's release strategy nobody has any confidence in it being that simple. Well our clear intention for point releases (7.6.1 to 7.6.1) is that they should break nothing. I am concerned that in your experience point releases are “moderately violent”. We go to some pains to make sure that we don’t break anything.If we don’t succeed on this point-release policy, please do tell us when the release candidate comes out. If we don’t know we are causing pain, we can’t stop inflicting it :-) (Major releases are another matter. There, things are likely to break.) Simon From: Brandon Allbery [mailto:allber...@gmail.com] Sent: 09 February 2013 13:41 To: Simon Peyton-Jones Cc: Carter Schonwald; Manuel Chakravarty; parallel-haskell; Mark Lentczner; GHC Users List; ghc-d...@haskell.org; Edsko de Vries Subject: Re: GHC 7.8 release? On Sat, Feb 9, 2013 at 6:27 AM, Simon Peyton-Jones simo...@microsoft.commailto:simo...@microsoft.com wrote: In short, I think we already have the situation that you desire. Perhaps we just need to market it better? Or am I mistaken? Except the current question is about how ghc releases interact with the Platform; this thread was set off by a question about getting 7.6.2 into the next Platform And the main issue there is that ghc releases tend to break things and need a lot of testing in general to make it into the Platform; while this would be expected anyway, even a point release (7.6.2 vs. 7.6.1) of ghc tends to be moderately violent with respect to the Platform. Ideally, such a point release should not be difficult to slot in because it should be compatible modulo bug fixes, but with ghc's release strategy nobody has any confidence in it being that simple. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.commailto:allber...@gmail.com ballb...@sinenomine.netmailto:ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On 10/02/13 15:36, Simon Peyton-Jones wrote: We seem to be circling ever closer to consensus here! Yay! Indeed! Good :-) However, I’m not getting the bit about API changing vs non-API changing. Firstly I don’t know which APIs are intended. The GHC API is essentially GHC itself, so it changes daily. Maybe you mean the base package? Or what? I suspect you mean that a “non-API-changing” release absolutely guarantees to compile any package that compiled with the previous version. If so, that is a very strong constraint indeed. We do observe it for patch releases for GHC (e g 7.6.2 should compile anything that 7.6.1 compiles). But I think it would be difficult to guarantee for anything beyond a patch release. Every single commit (and the commit rate is many/day) would have to be evaluated against this criterion. And if it failed the criterion, it would have to go on a API-breaking HEAD. In effect we’d have two HEADs. I can’t see us sustaining this. And I don’t yet really see why it’s necessary. If you don’t want an API-breaking change, stick with the patch releases. So, we have a channel for non-API-breaking changes already: the patch releases. So that means we already have all three channels! Mark is asking for major GHC releases every year at the most, preferably less frequently. That means major GHC releases in the sense that we do them now, where libraries change, and a wave of package updates are required to get everything working. Johan, Manuel and Carter are saying that they want releases that add features but don't break code, i.e. a non-API-breaking release, as a way to get the new bits into the hands of the punters sooner. This is something that we don't do right now, and it would entail a change to our workflow and release schedule. It doesn't mean no API changes at all - we would have to allow APIs to be extended, because many feature additions come with new primops, or new supporting code in the ghc-prim or base packages. The package version policy states precisely what it means to extend an API (http://www.haskell.org/haskellwiki/Package_versioning_policy) and most third-party packages will still work so long as we only bump the minor versions of the packages that come with GHC. The GHC package itself would have to be exempt, because it contains every module in GHC, and hence would be impossible to keep stable if we are modifying the compiler to add new features. Of course it's not practical to maintain an extra branch of GHC for non-API-breaking development - two branches is already plenty. So there would need to be an API-freeze for a while between the major release and the non-API-breaking release, during which time people developing API changes would need to work on branches. Is it workable? I'm not sure, but I think it's worth a try. I wouldn't want to see this replace the patchlevel bugfix releases that we already do, and as Ian points out, there isn't a lot of room in the release schedule for more releases, unless we stretch out the timescales, doing major releases less frequently. Cheers, Simon ·Haskell Platform ·Patch-level releases ·New releases if that’s so, all we need is better signposting. And I’m all for that! Have I got this right? Simon *From:*Mark Lentczner [mailto:mark.lentcz...@gmail.com] *Sent:* 09 February 2013 17:48 *To:* Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon Peyton-Jones; Mark Lentczner; andreas.voel...@gmail.com; Carter Schonwald; kosti...@gmail.com; Edsko de Vries; ghc-d...@haskell.org; glasgow-haskell-users *Subject:* Re: GHC 7.8 release? We seem to be circling ever closer to consensus here! Yay! I think the distinction of non-API breaking and API breaking release is very important. Refining SPJ's trifecta: *Haskell Platform* comes out twice a year. It is based on very stable version of GHC, and intention is that people can just assume things on Hackage work with it. These are named for the year and sequence of the release: 2013.2, 2013.2.1, 2013.4,... *Non-API breaking releases* can come out as often as desired. However, the version that is current as of mid-Feb. and mid-Aug. will be the ones considered for HP inclusion. By non-API breaking we mean the whole API surface including all the libraries bundled with GHC, as well as the operation of ghc, cabal, ghc-pkg, etc. Additions of features that must be explicitly enabled are okay. Additions of new APIs into existing modules are discouraged: Much code often imports base modules wholesale, and name clashes could easily result. These should never bump the major revision number: 7.4.1, 7.4.2... *API breaking releases* happen by being released into a separate channel when ready for library owners to look at them. This channel should probably go through several stages: Ready for core package owners to work with, then HP package owners, then all
RE: GHC 7.8 release?
What I am still missing is this: | Mark is asking for major GHC releases every year at the most, preferably | less frequently. That means major GHC releases in the sense that we do | them now, where libraries change, and a wave of package updates are | required to get everything working. What causes the wave of package updates? Just because GHC 7.8 (say) comes out, no package author need lift a finger. The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates. Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP. But there is no reason why package authors should respond to GHC releases, provided we signpost it accurately. You may ask what use is a GHC release that doesn't cause a wave of updates? And hence that doesn't work with at least some libraries. Well, it's a very useful forcing function to get new features actually out and tested. Of course we could just not do that, and say build from source, but a release brings a welcome discipline. But under this story, release or not-release would be a Little Deal, not a Big Deal. The benefits are modest; the costs are modest. In short, I'm continuing to propose that we stick to the current story, but signpost it better. If it ain't broke, don't fix it --- or at least fix only the bits that are broken, which is the signposting. Simon | | Johan, Manuel and Carter are saying that they want releases that add | features but don't break code, i.e. a non-API-breaking release, as a way | to get the new bits into the hands of the punters sooner. This is | something that we don't do right now, and it would entail a change to | our workflow and release schedule. | | It doesn't mean no API changes at all - we would have to allow APIs to | be extended, because many feature additions come with new primops, or | new supporting code in the ghc-prim or base packages. The package | version policy states precisely what it means to extend an API | (http://www.haskell.org/haskellwiki/Package_versioning_policy) and most | third-party packages will still work so long as we only bump the minor | versions of the packages that come with GHC. | | The GHC package itself would have to be exempt, because it contains | every module in GHC, and hence would be impossible to keep stable if we | are modifying the compiler to add new features. | | Of course it's not practical to maintain an extra branch of GHC for | non-API-breaking development - two branches is already plenty. So there | would need to be an API-freeze for a while between the major release and | the non-API-breaking release, during which time people developing API | changes would need to work on branches. | | Is it workable? I'm not sure, but I think it's worth a try. I wouldn't | want to see this replace the patchlevel bugfix releases that we already | do, and as Ian points out, there isn't a lot of room in the release | schedule for more releases, unless we stretch out the timescales, doing | major releases less frequently. | | Cheers, | Simon | | | ·Haskell Platform | | ·Patch-level releases | | ·New releases | | | if that’s so, all we need is better signposting. And I’m all for that! | | Have I got this right? | | | Simon | | *From:*Mark Lentczner [mailto:mark.lentcz...@gmail.com] | *Sent:* 09 February 2013 17:48 | *To:* Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon | Peyton-Jones; Mark Lentczner; andreas.voel...@gmail.com; Carter | Schonwald; kosti...@gmail.com; Edsko de Vries; ghc-d...@haskell.org; | glasgow-haskell-users | *Subject:* Re: GHC 7.8 release? | | We seem to be circling ever closer to consensus here! Yay! | | I think the distinction of non-API breaking and API breaking release is | very important. Refining SPJ's trifecta: | | *Haskell Platform* comes out twice a year. It is based on very | stable version of GHC, and intention is that people can just assume | things on Hackage work with it. These are named for the year and | sequence of the release: 2013.2, 2013.2.1, 2013.4,... | | *Non-API breaking releases* can come out as often as desired. | However, the version that is current as of mid-Feb. and mid-Aug. | will be the ones considered for HP inclusion. By non-API breaking we | mean the whole API surface including all the libraries bundled with | GHC, as well as the operation of ghc, cabal, ghc-pkg, etc. Additions | of features that must be explicitly enabled are okay. Additions of | new APIs into existing modules are discouraged: Much code often | imports base modules wholesale, and name clashes could easily | result. These should never bump the major revision number: 7.4.1, | 7.4.2... | | *API breaking
Re: GHC 7.8 release?
On Sun, Feb 10, 2013 at 09:02:18PM +, Simon Peyton-Jones wrote: You may ask what use is a GHC release that doesn't cause a wave of updates? And hence that doesn't work with at least some libraries. Well, it's a very useful forcing function to get new features actually out and tested. But the way you test new features is to write programs that use them, and programs depend on libraries. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On 10 February 2013 13:02, Simon Peyton-Jones simo...@microsoft.com wrote: What I am still missing is this: | Mark is asking for major GHC releases every year at the most, preferably | less frequently. That means major GHC releases in the sense that we do | them now, where libraries change, and a wave of package updates are | required to get everything working. What causes the wave of package updates? Just because GHC 7.8 (say) comes out, no package author need lift a finger. The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates. Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP. But there is no reason why package authors should respond to GHC releases, provided we signpost it accurately. You may ask what use is a GHC release that doesn't cause a wave of updates? And hence that doesn't work with at least some libraries. Well, it's a very useful forcing function to get new features actually out and tested. Of course we could just not do that, and say build from source, but a release brings a welcome discipline. But under this story, release or not-release would be a Little Deal, not a Big Deal. The benefits are modest; the costs are modest. In short, I'm continuing to propose that we stick to the current story, but signpost it better. If it ain't broke, don't fix it --- or at least fix only the bits that are broken, which is the signposting. My understanding of the proposed changes (which I'm also supportive of) is to separate GHC improvements that break existing libraries (or perhaps even simply add language level features), and those that are improvements under-the-hood (e.g., bug fixes, performance improvements). So rather than 7.8 be a huge single release containing new type level features, SIMD, the new code-generator. There would be two releases, one containing just say the new-code-generator, improvements to the IO manager, potentially also DPH... another release would containing new language level improvements. So then HP can benefit from improvements to the existing language and API without having to also pull in breaking (or just extending) changes... It's the issue of a research compiler Vs. and industrial compiler and managing that more explicitly in the release model. Cheers, David Simon | | Johan, Manuel and Carter are saying that they want releases that add | features but don't break code, i.e. a non-API-breaking release, as a way | to get the new bits into the hands of the punters sooner. This is | something that we don't do right now, and it would entail a change to | our workflow and release schedule. | | It doesn't mean no API changes at all - we would have to allow APIs to | be extended, because many feature additions come with new primops, or | new supporting code in the ghc-prim or base packages. The package | version policy states precisely what it means to extend an API | (http://www.haskell.org/haskellwiki/Package_versioning_policy) and most | third-party packages will still work so long as we only bump the minor | versions of the packages that come with GHC. | | The GHC package itself would have to be exempt, because it contains | every module in GHC, and hence would be impossible to keep stable if we | are modifying the compiler to add new features. | | Of course it's not practical to maintain an extra branch of GHC for | non-API-breaking development - two branches is already plenty. So there | would need to be an API-freeze for a while between the major release and | the non-API-breaking release, during which time people developing API | changes would need to work on branches. | | Is it workable? I'm not sure, but I think it's worth a try. I wouldn't | want to see this replace the patchlevel bugfix releases that we already | do, and as Ian points out, there isn't a lot of room in the release | schedule for more releases, unless we stretch out the timescales, doing | major releases less frequently. | | Cheers, | Simon | | | ·Haskell Platform | | ·Patch-level releases | | ·New releases | | | if that’s so, all we need is better signposting. And I’m all for that! | | Have I got this right? | | | Simon | | *From:*Mark Lentczner [mailto:mark.lentcz...@gmail.com] | *Sent:* 09 February 2013 17:48 | *To:* Simon Marlow; Manuel M T Chakravarty; Johan Tibell; Simon | Peyton-Jones; Mark Lentczner; andreas.voel...@gmail.com; Carter | Schonwald; kosti...@gmail.com; Edsko de Vries; ghc-d...@haskell.org; | glasgow-haskell-users | *Subject:* Re: GHC 7.8 release? | | We seem to be circling ever closer to consensus here! Yay! | | I think the distinction of non-API breaking and API breaking release is | very important. Refining SPJ's
RE: GHC 7.8 release?
| You may ask what use is a GHC release that doesn't cause a wave of updates? | And hence that doesn't work with at least some libraries. Well, it's a very useful | forcing function to get new features actually out and tested. | | But the way you test new features is to write programs that use them, | and programs depend on libraries. That is of course ideal, but the ideal carries costs. A half way house is a release whose library support will be patchy. Not such good testing, but much lower costs. But still (I think) a lot more testing than compile HEAD gives us. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Sun, Feb 10, 2013 at 09:30:23PM +, Simon Peyton-Jones wrote: | You may ask what use is a GHC release that doesn't cause a wave of updates? | And hence that doesn't work with at least some libraries. Well, it's a very useful | forcing function to get new features actually out and tested. | | But the way you test new features is to write programs that use them, | and programs depend on libraries. That is of course ideal, but the ideal carries costs. A half way house is a release whose library support will be patchy. But that's not what happens. GHC 7.8 is released. Someone installs it in order to try to use TypeHoles when developing their program. But their program depends on text, so they send Bryan a mail saying that text doesn't build with 7.8. And so the wave of updates begins. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On 10/02/2013 21:43, Ian Lynagh wrote: On Sun, Feb 10, 2013 at 09:30:23PM +, Simon Peyton-Jones wrote: | You may ask what use is a GHC release that doesn't cause a wave of updates? | And hence that doesn't work with at least some libraries. Well, it's a very useful | forcing function to get new features actually out and tested. | | But the way you test new features is to write programs that use them, | and programs depend on libraries. That is of course ideal, but the ideal carries costs. A half way house is a release whose library support will be patchy. But that's not what happens. GHC 7.8 is released. Someone installs it in order to try to use TypeHoles when developing their program. But their program depends on text, so they send Bryan a mail saying that text doesn't build with 7.8. And so the wave of updates begins. As the maintainer of a low-level package (HTTP), I certainly see this kind of pressure starting even before a GHC release - e.g. https://github.com/haskell/HTTP/issues/36 As one of the maintainers of a high-level tool (darcs) that aims to always build against the current HP, I generate this kind of pressure myself: once GHC is released, I expect it to be in the HP within 3-6 months, so I need to get started quickly. I can't even check darcs itself until the dependencies work. I don't think there are any easy answers :-/ Ganesh ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Yes, exactly this. A release where the versions of base, and all other baked in libraries are only minor version bumps and where breaking changes are localized to relatively experimental language features / extensions and GHC specific APIs would ideal. Eg: I'm OK having to patch ghc-mod so it works with a new intermediate GHC release. (Esp since it uses GHC internal apis) The new scheduler improvements, the recent doh work , the great SIMD work / code generator improvments, the type level nats, ordered type families, the overloaded list syntax, All of these extensions and associated API augmentations should not break stable libraries, at least on minor version bumps, cause 1) maybe experimental new APIs can be included in minor releases as separate explicitly experimental modules (this gives a way of including new functionality in a minor release) 2) generally type checking / inference on stable code that doesn't enable new features stays the same. I'm probably overlooking some pieces or. Details, and I'm largely restating what Johan and Manuel have communicated. -Carter On Feb 10, 2013 4:43 PM, Ian Lynagh i...@well-typed.com wrote: On Sun, Feb 10, 2013 at 09:30:23PM +, Simon Peyton-Jones wrote: | You may ask what use is a GHC release that doesn't cause a wave of updates? | And hence that doesn't work with at least some libraries. Well, it's a very useful | forcing function to get new features actually out and tested. | | But the way you test new features is to write programs that use them, | and programs depend on libraries. That is of course ideal, but the ideal carries costs. A half way house is a release whose library support will be patchy. But that's not what happens. GHC 7.8 is released. Someone installs it in order to try to use TypeHoles when developing their program. But their program depends on text, so they send Bryan a mail saying that text doesn't build with 7.8. And so the wave of updates begins. Thanks Ian ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Sun, Feb 10, 2013 at 3:16 PM, Ian Lynagh i...@well-typed.com wrote: On Sun, Feb 10, 2013 at 09:02:18PM +, Simon Peyton-Jones wrote: You may ask what use is a GHC release that doesn't cause a wave of updates? And hence that doesn't work with at least some libraries. Well, it's a very useful forcing function to get new features actually out and tested. But the way you test new features is to write programs that use them, and programs depend on libraries. Thanks Ian Releasing GHC early and often (possibly with API breakage) isn't really the problem. The real problem is how to coordinate with library authors (e.g. Haskell Platform), etc. I suspect GHC should continue to offer a platform for research and experiments. That is much harder if you curtail the ability to release GHC early and often. -- Gaby ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Well said. Having a more aggressive release cycle is another interesting perspective. On Feb 10, 2013 6:21 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Sun, Feb 10, 2013 at 3:16 PM, Ian Lynagh i...@well-typed.com wrote: On Sun, Feb 10, 2013 at 09:02:18PM +, Simon Peyton-Jones wrote: You may ask what use is a GHC release that doesn't cause a wave of updates? And hence that doesn't work with at least some libraries. Well, it's a very useful forcing function to get new features actually out and tested. But the way you test new features is to write programs that use them, and programs depend on libraries. Thanks Ian Releasing GHC early and often (possibly with API breakage) isn't really the problem. The real problem is how to coordinate with library authors (e.g. Haskell Platform), etc. I suspect GHC should continue to offer a platform for research and experiments. That is much harder if you curtail the ability to release GHC early and often. -- Gaby ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones simo...@microsoft.comwrote: What causes the wave of package updates? Just because GHC 7.8 (say) comes out, no package author need lift a finger. The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates. Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP. (a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. You *might* be able to control expectations with respect to (a); (b) is not subject to any variety of reason. It will produce as much pressure as it has users, plus multiply that pressure by the number of package authors who are also users. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
While I'm notionally in favor of decoupling API-breaking changes from non-API breaking changes, there are two major difficulties: GHC.Prim and Template Haskell. Should a non-API-breaking change mean that GHC.Prim is immutable? If so, this greatly restricts GHC's development. If not, it means that a large chunk of hackage will become unbuildable due to deps on vector and primitive. With Template Haskell the situation is largely similar, although the deps are different. What I would like to see are more patch-level bugfix releases. I suspect the reason we don't have more is that making a release is a lot of work. So, Ian, what needs to happen to make more frequent patch releases feasible? On Mon, Feb 11, 2013 at 7:42 AM, Carter Schonwald carter.schonw...@gmail.com wrote: Well said. Having a more aggressive release cycle is another interesting perspective. On Feb 10, 2013 6:21 PM, Gabriel Dos Reis g...@integrable-solutions.net wrote: On Sun, Feb 10, 2013 at 3:16 PM, Ian Lynagh i...@well-typed.com wrote: On Sun, Feb 10, 2013 at 09:02:18PM +, Simon Peyton-Jones wrote: You may ask what use is a GHC release that doesn't cause a wave of updates? And hence that doesn't work with at least some libraries. Well, it's a very useful forcing function to get new features actually out and tested. But the way you test new features is to write programs that use them, and programs depend on libraries. Thanks Ian Releasing GHC early and often (possibly with API breakage) isn't really the problem. The real problem is how to coordinate with library authors (e.g. Haskell Platform), etc. I suspect GHC should continue to offer a platform for research and experiments. That is much harder if you curtail the ability to release GHC early and often. -- Gaby ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 7.8 release?
If there's a path to having a release strategy as Manuel suggests, and having an intermediate release with the new vector primops, type extensions and such goodness, then I'm all for it. A lot of these bits are things ill start using almost immediately in production / real software, esp if I'm not needing to patch every stable library beyond maybe relaxing versioning constraints. Let me suggest once more a possible path, along the lines you suggest ·For people who value stability: use the Haskell Platform. Ignore GHC releases. ·For people who want as many features as possible: use GHC releases. ·For people who want to live on the bleeding edge: build HEAD from source The Haskell Platform decides which GHC release to use, advertises that to package authors who do whatever updates are needed. HP may perfectly sensibly skip an entire release entirely. In short, I think we already have the situation that you desire. Perhaps we just need to market it better? Or am I mistaken? Simon From: Carter Schonwald [mailto:carter.schonw...@gmail.com] Sent: 09 February 2013 02:45 To: Manuel Chakravarty Cc: GHC Users List; ghc-d...@haskell.org; Andreas Voellmy; Simon Peyton-Jones; Edsko de Vries; Mark Lentczner; Johan Tibell; parallel-haskell Subject: Re: GHC 7.8 release? +10^100 to Johan and Manuel. Breaking changes on pieces that aren't experimental is the main compatibility / new version pain, and I say this as someone who's spent time before and around the 7.4 and 7.6 releases testing out lots of major packages and sending a few patches to various maintainers. If there's a path to having a release strategy as Manuel suggests, and having an intermediate release with the new vector primops, type extensions and such goodness, then I'm all for it. A lot of these bits are things ill start using almost immediately in production / real software, esp if I'm not needing to patch every stable library beyond maybe relaxing versioning constraints. -Carter On Feb 8, 2013 9:05 PM, Manuel M T Chakravarty c...@cse.unsw.edu.aumailto:c...@cse.unsw.edu.au wrote: I completely agree with Johan. The problem is to change core APIs too fast. Adding, say, SIMD instructions or having a new type extension (that needs to be explicitly activated with a -X option) shouldn't break packages. I'm all for restricting major API changes to once a year, but why can't we have multiple updates to the code generator per year or generally release that don't affect a large number of packages on Hackage? Manuel Johan Tibell johan.tib...@gmail.commailto:johan.tib...@gmail.com: On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow marlo...@gmail.commailto:marlo...@gmail.com wrote: For a while we've been doing one major release per year, and 1-2 minor releases. We have a big sign at the top of the download page directing people to the platform. We arrived here after various discussions in the past - there were always a group of people that wanted stability, and a roughly equally vocal group of people who wanted the latest bits. So we settled on one API-breaking change per year as a compromise. Since then, the number of packages has ballooned, and there's a new factor in the equation: the cost to the ecosystem of an API-breaking release of GHC. All that updating of packages collectively costs the community a lot of time, for little benefit. Lots of package updates contributes to Cabal Hell. The package updates need to happen before the platform picks up the GHC release, so that when it goes into the platform, the packages are ready. So I think, if anything, there's pressure to have fewer major releases of GHC. However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months. We're getting too efficient at making releases! I think we want to decouple GHC major releases (as in, we did lots of work) from API breaking releases. For example, GCC has lots of major (or big) releases, but rarely, if ever, break programs. I'd be delighted to see a release once in a while that made my programs faster/smaller/buggy without breaking any of them. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
I agree too - I think it would be great to have non-API-breaking releases with new features. So let's think about how that could work. Some features add APIs, e.g. SIMD adds new primops. So we have to define non-API-breaking as a minor version bump in the PVP sense; that is, you can add to an API but not change it. As a straw man, let's suppose we want to do annual API releases in September, with intermediate non-API releases in February. Both would be classed as major, and bump the GHC major version, but the Feb releases would only be allowed to bump minor versions of packages. (except perhaps the version of the GHC package, which is impossible to keep stable if we change the compiler). So how to manage the repos. We could have three branches, but that doesn't seem practical. Probably the best way forward is to develop new features on separate branches and merge them into master at the appropriate time - i.e. API-breaking feature branches could only be merged in after the Feb release. Thoughts? Cheers, Simon On 09/02/13 02:04, Manuel M T Chakravarty wrote: I completely agree with Johan. The problem is to change core APIs too fast. Adding, say, SIMD instructions or having a new type extension (that needs to be explicitly activated with a -X option) shouldn't break packages. I'm all for restricting major API changes to once a year, but why can't we have multiple updates to the code generator per year or generally release that don't affect a large number of packages on Hackage? Manuel Johan Tibell johan.tib...@gmail.com mailto:johan.tib...@gmail.com: On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: For a while we've been doing one major release per year, and 1-2 minor releases. We have a big sign at the top of the download page directing people to the platform. We arrived here after various discussions in the past - there were always a group of people that wanted stability, and a roughly equally vocal group of people who wanted the latest bits. So we settled on one API-breaking change per year as a compromise. Since then, the number of packages has ballooned, and there's a new factor in the equation: the cost to the ecosystem of an API-breaking release of GHC. All that updating of packages collectively costs the community a lot of time, for little benefit. Lots of package updates contributes to Cabal Hell. The package updates need to happen before the platform picks up the GHC release, so that when it goes into the platform, the packages are ready. So I think, if anything, there's pressure to have fewer major releases of GHC. However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months. We're getting too efficient at making releases! I think we want to decouple GHC major releases (as in, we did lots of work) from API breaking releases. For example, GCC has lots of major (or big) releases, but rarely, if ever, break programs. I'd be delighted to see a release once in a while that made my programs faster/smaller/buggy without breaking any of them. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Sat, Feb 9, 2013 at 6:27 AM, Simon Peyton-Jones simo...@microsoft.comwrote: In short, I think we already have the situation that you desire. Perhaps we just need to market it better? ** ** Or am I mistaken? Except the current question is about how ghc releases interact with the Platform; this thread was set off by a question about getting 7.6.2 into the next Platform And the main issue there is that ghc releases tend to break things and need a lot of testing in general to make it into the Platform; while this would be expected anyway, even a point release (7.6.2 vs. 7.6.1) of ghc tends to be moderately violent with respect to the Platform. Ideally, such a point release should not be difficult to slot in because it should be compatible modulo bug fixes, but with ghc's release strategy nobody has any confidence in it being that simple. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Sat, Feb 09, 2013 at 12:06:12PM +, Simon Marlow wrote: As a straw man, let's suppose we want to do annual API releases in September, with intermediate non-API releases in February. That's a non-API release 5 months after the API release. 6.10.2 was 5 months after 6.10.1 (.3 was 1 month later, .4 a further 2) 6.12.2 was 4 months after 6.12.1 (.3 was 2 months later) 7.0.2 was 3.5 months after 7.0.1 (.3 was 1 month later, .4 a further 3) 7.2.2 was 3 months after 7.2.1 7.4.2 was 4 months after 7.4.1 7.6.2 was 4.5 months after 7.6.2 so if we do non-API releases, then perhaps it would make sense to stop doing minor releases (unless a release turns out to just be broken). Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On 8 Feb 2013, at 05:18, Carter Schonwald wrote: johan, how do you and Bryan have those jenkin's nodes setup? (I'm planning to setup something similar for my own use, and seeing how thats setup would be awesome) Likewise, I'm in the process of setting up Elastic Bamboo on EC2 for Cloud Haskell and would be very interested in seeing how you've dealt with multiple versions of GHC. Cheers, Tim ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Fri, Feb 8, 2013 at 1:29 AM, Tim Watson watson.timo...@gmail.com wrote: Likewise, I'm in the process of setting up Elastic Bamboo on EC2 for Cloud Haskell and would be very interested in seeing how you've dealt with multiple versions of GHC. It's easy to parameterize builds in Jenkins based on different values of an environment variable, so Johan and I just have different versions of GHC installed side by side, and then set $GHC_VERSION to 7.6 7.4 7.2 7.0 6.12 (or whatever), put /usr/local/$GHC_VERSION/bin at the front of $PATH, and the right thing happens. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Hi Bryan, On 8 Feb 2013, at 11:53, Bryan O'Sullivan wrote: On Fri, Feb 8, 2013 at 1:29 AM, Tim Watson watson.timo...@gmail.com wrote: Likewise, I'm in the process of setting up Elastic Bamboo on EC2 for Cloud Haskell and would be very interested in seeing how you've dealt with multiple versions of GHC. It's easy to parameterize builds in Jenkins based on different values of an environment variable, so Johan and I just have different versions of GHC installed side by side, and then set $GHC_VERSION to 7.6 7.4 7.2 7.0 6.12 (or whatever), put /usr/local/$GHC_VERSION/bin at the front of $PATH, and the right thing happens. Ok cool, that's pretty much what I had in mind but I wasn't sure about installing dependencies and using cabal-install. In my development environment I quickly found that installing multiple GHCs and haskell-platform releases got a bit messy, so I was wondering if there was a recognised 'best way' to do this. I'll probably replicate what I've done with other things (such as Erlang) and manage it with ${PREFIX}/ghc/versions/... and symlink ${PREFIX}/ghc/current/... to avoid the path switching. Hopefully telling cabal-install to use ${PREFIX}/ghc/current/lib will 'just work' when installing dependencies as I switch between ghc versions. Cheers! Tim ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Thu, Feb 07, 2013 at 09:42:39AM -0800, Mark Lentczner wrote: I wish GHC would radically change it's release process. Things like 7.8 shouldn't be release as 7.8. That sounds major and stable. The web site will have 7.8 at the top. The warning to use the platform will fall flat because it makes the platform look out of date. Really, 7.8 should be in a different release channel, not on the front page. It should bake in that channel for six months - where only the third group of people will use it, until it is getting close to merge into main, at which point the fourth group will start to use it, so that the day it hits main, all the libraries just work. Ideally, the first two groups of people will not pay the slightest attention to it until it is further baked. It's a catch-22: We don't want people to use a new release until all the bugs have been found and fixed, and all the libraries have been updated. But if people don't use it, then the bugs won't be found and the libraries won't be updated. I think you're saying that you'd like the uptake of new GHC versions to be slower, which would mean fewer people would be using 7.6 now, but in the last few days I've seen the Debian guys have had to send mails to maintainers telling them that their packages don't work with 7.6: http://lists.debian.org/debian-haskell/2013/02/threads.html despite 7.6 having been out for 5 months and about to enter the HP. Perhaps more automatic Hackage building, with a group of people looking at the logs of failing packages and acting appropriately, is the way forward. Some cases (such as installation failed due to dependencies not being installable) you'd want to be handled automatically. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Fri, Feb 8, 2013 at 3:55 PM, Ian Lynagh i...@well-typed.com wrote: On Thu, Feb 07, 2013 at 09:42:39AM -0800, Mark Lentczner wrote: I wish GHC would radically change it's release process. Things like 7.8 shouldn't be release as 7.8. That sounds major and stable. The web site will have 7.8 at the top. The warning to use the platform will fall flat because it makes the platform look out of date. Really, 7.8 should be in a different release channel, not on the front page. It should bake in that channel for six months - where only the third group of people will use it, until it is getting close to merge into main, at which point the fourth group will start to use it, so that the day it hits main, all the libraries just work. Ideally, the first two groups of people will not pay the slightest attention to it until it is further baked. It's a catch-22: We don't want people to use a new release until all the bugs have been found and fixed, and all the libraries have been updated. But if people don't use it, then the bugs won't be found and the libraries won't be updated. I think you're saying that you'd like the uptake of new GHC versions to be slower, which would mean fewer people would be using 7.6 now, but in the last few days I've seen the Debian guys have had to send mails to maintainers telling them that their packages don't work with 7.6: http://lists.debian.org/debian-haskell/2013/02/threads.html despite 7.6 having been out for 5 months and about to enter the HP. Perhaps more automatic Hackage building, with a group of people looking at the logs of failing packages and acting appropriately, is the way forward. Some cases (such as installation failed due to dependencies not being installable) you'd want to be handled automatically. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users This is an issue I'm hoping Stackage will be able to help address. Currently, we're running daily builds of the Stackage package set (currently at about 330 packages) using the most recent Haskell Platform. However, I'm hoping to augment this with GHC 7.6.2 as well (obviously dropping the Haskell Platform version constraints at that point, as they would not be compatible). We could also theoretically include release candidates in this process, which I think would help flesh out bugs and drive support for newer GHCs more quickly. Michael ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
For a while we've been doing one major release per year, and 1-2 minor releases. We have a big sign at the top of the download page directing people to the platform. We arrived here after various discussions in the past - there were always a group of people that wanted stability, and a roughly equally vocal group of people who wanted the latest bits. So we settled on one API-breaking change per year as a compromise. Since then, the number of packages has ballooned, and there's a new factor in the equation: the cost to the ecosystem of an API-breaking release of GHC. All that updating of packages collectively costs the community a lot of time, for little benefit. Lots of package updates contributes to Cabal Hell. The package updates need to happen before the platform picks up the GHC release, so that when it goes into the platform, the packages are ready. So I think, if anything, there's pressure to have fewer major releases of GHC. However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months. We're getting too efficient at making releases! My feeling is that this pace is too fast. You might argue that with better tools and infrastructure the community wouldn't have so much work to do for each release, and I wholeheartedly agree. Perhaps if we stop releasing GHC so frequently they'll have time to work on it :) Releasing early and often is great, but at the moment it's having negative effects on the ecosystem (arguably due to deficiencies in the infrastructure). Does this strike a chord with anyone, or have I got the wrong impression and everyone is happy with the pace? Cheers, Simon On 07/02/13 18:15, Simon Peyton-Jones wrote: It’s fairly simple in my mind. There are two “channels” (if I understand Mark’s terminology right): ·Haskell Platform: oA stable development environment, lots of libraries known to work oNewcomers, and people who value stability, should use the Haskell Platform oHP comes with a particular version of GHC, probably not the hottest new one, but that doesn’t matter. It works. ·GHC home page downloads: oMore features but not so stable oLibraries not guaranteed to work oWorth releasing, though, as a forcing function to fix bugs, and as a checkpoint for people to test, so that by the time the HP adopts a particular version it is reasonably solid. So we already have the two channels Mark asks for, don’t we? One is called the Haskell Platform and one is called the GHC home page. That leaves a PR issue: we really /don’t/ want newcomers or Joe Users wanting the “new shiny”. They want the Haskell Platform, and as Mark says those users should not pay the slightest attention until it appears in the Haskell Platform. So perhaps we principally need a way to point people away from GHC and towards HP? eg We could prominently say at every download point “Stop! Are you sure you want this? You might be better off with the Haskell Platform! Here’s why...”. Have I understood aright? If so, how could we achieve the right social dynamics? Our goal is to let people who value stability get stability, while the hot-shots race along in a different channel and pay the price of flat tires etc. PS: absolutely right to use 7.6.2 for the next HP. Don’t even think about 7.8. Simon *From:*Mark Lentczner [mailto:mark.lentcz...@gmail.com] *Sent:* 07 February 2013 17:43 *To:* Simon Peyton-Jones *Cc:* andreas.voel...@gmail.com; Carter Schonwald; GHC users; Simon Marlow; parallel-haskell; kosti...@gmail.com; Edsko de Vries; ghc-d...@haskell.org *Subject:* Re: GHC 7.8 release? I'd say the window for 7.8 in the platform is about closed. If 7.8 were to be release in the next two weeks that would be just about the least amount of time I'd want to see for libraries in the platform to get all stable with the GHC version. And we'd also be counting on the GHC team to be quickly responding to bugs so that there could be a point release of 7.8 mid-April. Historically, none of that seems likely. So my current trajectory is to base HP 2013.2.0.0 on GHC 7.6.2. Since 7.8 will seems like it will be released before May, we will be faced again with the bad public relations issue: Everyone will want the new shiny and be confused as to why the platform is such a laggard. We'll see four reactions: * New comers who are starting out and figure they should use the latest... Many will try to use 7.8, half the libraries on hackage won't work, things will be wonky, and they'll have a poor experience. * People doing production / project work will stay on 7.6 and ignore 7.8 for a few months. * The small group of people exploring the frontiers will know how to get things set up and be happy. * Eventually library authors will get around to making sure their stuff will work with it. I wish GHC would radically change it's release process. Things like 7.8 shouldn't
Re: GHC 7.8 release?
On Fri, Feb 08, 2013 at 02:28:20PM +, Simon Marlow wrote: So I think, if anything, there's pressure to have fewer major releases of GHC. However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months. We're getting too efficient at making releases! 7.2 was billed as a technology preview rather than a regular stable release. However, it still required just as much effort as a regular stable release, both for us (we probably spent just as much time trying to make it bug-free, making builds, making docs, etc) and for the community (libraries still needed to adjust dependencies etc). One result of that extra effort was that the 7.4 release got delayed, and the delay was magnified by pushing it over the Christmas period. 7.6 was released roughly according to the regular yearly release plan (although the 7.4 delay made the gap between the two shorter). So in my opinion, 7.2 was a bad idea (but I don't think anyone knew that before we tried it), and I'd agree that we'd be better sticking to not-more-than-yearly major releases. I wouldn't oppose less-than-yearly (e.g. every 18 months) if that makes life easier for distros, library maintainers, the HP, etc. But I wouldn't advocate it either; from GHC's point of view, historically we've always had enough new stuff to justify a new major release after a year. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
(sorry for re-post, but the first one got rejected from some lists due to too many recipients) On Fri, Feb 8, 2013 at 2:28 PM, Simon Marlow marlo...@gmail.com wrote: Does this strike a chord with anyone, or have I got the wrong impression and everyone is happy with the pace? I am happy with the pace; I like the release early, release often approach. The HP is not forced to use the latest GHC, and the GHC download page already clearly directs users to the HP. Slowing down GHC releases will slow down adoption of new features, because while installing GHC might be harder than installing the HP, installing GHC HEAD is harder. My experience is that almost no one, apart from GHC devs, has HEAD, and they aren't willing to install it just to play with one new feature. Once a new compiler version is out, however, many people are happy to try it, even if it has no accompanying HP. Cheers, Pedro ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Fri, Feb 08, 2013 at 02:28:20PM +, Simon Marlow wrote: [..] So I think, if anything, there's pressure to have fewer major releases of GHC. However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months. We're getting too efficient at making releases! My feeling is that this pace is too fast. [..] The GHC versions appear too fast (last 13 years). If asked, I would ask to make them to appear 5 times slower. Regards, -- Sergei ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow marlo...@gmail.com wrote: For a while we've been doing one major release per year, and 1-2 minor releases. We have a big sign at the top of the download page directing people to the platform. We arrived here after various discussions in the past - there were always a group of people that wanted stability, and a roughly equally vocal group of people who wanted the latest bits. So we settled on one API-breaking change per year as a compromise. Since then, the number of packages has ballooned, and there's a new factor in the equation: the cost to the ecosystem of an API-breaking release of GHC. All that updating of packages collectively costs the community a lot of time, for little benefit. Lots of package updates contributes to Cabal Hell. The package updates need to happen before the platform picks up the GHC release, so that when it goes into the platform, the packages are ready. So I think, if anything, there's pressure to have fewer major releases of GHC. However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months. We're getting too efficient at making releases! I think we want to decouple GHC major releases (as in, we did lots of work) from API breaking releases. For example, GCC has lots of major (or big) releases, but rarely, if ever, break programs. I'd be delighted to see a release once in a while that made my programs faster/smaller/buggy without breaking any of them. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
I completely agree with Johan. The problem is to change core APIs too fast. Adding, say, SIMD instructions or having a new type extension (that needs to be explicitly activated with a -X option) shouldn't break packages. I'm all for restricting major API changes to once a year, but why can't we have multiple updates to the code generator per year or generally release that don't affect a large number of packages on Hackage? Manuel Johan Tibell johan.tib...@gmail.com: On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow marlo...@gmail.com wrote: For a while we've been doing one major release per year, and 1-2 minor releases. We have a big sign at the top of the download page directing people to the platform. We arrived here after various discussions in the past - there were always a group of people that wanted stability, and a roughly equally vocal group of people who wanted the latest bits. So we settled on one API-breaking change per year as a compromise. Since then, the number of packages has ballooned, and there's a new factor in the equation: the cost to the ecosystem of an API-breaking release of GHC. All that updating of packages collectively costs the community a lot of time, for little benefit. Lots of package updates contributes to Cabal Hell. The package updates need to happen before the platform picks up the GHC release, so that when it goes into the platform, the packages are ready. So I think, if anything, there's pressure to have fewer major releases of GHC. However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months. We're getting too efficient at making releases! I think we want to decouple GHC major releases (as in, we did lots of work) from API breaking releases. For example, GCC has lots of major (or big) releases, but rarely, if ever, break programs. I'd be delighted to see a release once in a while that made my programs faster/smaller/buggy without breaking any of them. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
+10^100 to Johan and Manuel. Breaking changes on pieces that aren't experimental is the main compatibility / new version pain, and I say this as someone who's spent time before and around the 7.4 and 7.6 releases testing out lots of major packages and sending a few patches to various maintainers. If there's a path to having a release strategy as Manuel suggests, and having an intermediate release with the new vector primops, type extensions and such goodness, then I'm all for it. A lot of these bits are things ill start using almost immediately in production / real software, esp if I'm not needing to patch every stable library beyond maybe relaxing versioning constraints. -Carter On Feb 8, 2013 9:05 PM, Manuel M T Chakravarty c...@cse.unsw.edu.au wrote: I completely agree with Johan. The problem is to change core APIs too fast. Adding, say, SIMD instructions or having a new type extension (that needs to be explicitly activated with a -X option) shouldn't break packages. I'm all for restricting major API changes to once a year, but why can't we have multiple updates to the code generator per year or generally release that don't affect a large number of packages on Hackage? Manuel Johan Tibell johan.tib...@gmail.com: On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow marlo...@gmail.com wrote: For a while we've been doing one major release per year, and 1-2 minor releases. We have a big sign at the top of the download page directing people to the platform. We arrived here after various discussions in the past - there were always a group of people that wanted stability, and a roughly equally vocal group of people who wanted the latest bits. So we settled on one API-breaking change per year as a compromise. Since then, the number of packages has ballooned, and there's a new factor in the equation: the cost to the ecosystem of an API-breaking release of GHC. All that updating of packages collectively costs the community a lot of time, for little benefit. Lots of package updates contributes to Cabal Hell. The package updates need to happen before the platform picks up the GHC release, so that when it goes into the platform, the packages are ready. So I think, if anything, there's pressure to have fewer major releases of GHC. However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months. We're getting too efficient at making releases! I think we want to decouple GHC major releases (as in, we did lots of work) from API breaking releases. For example, GCC has lots of major (or big) releases, but rarely, if ever, break programs. I'd be delighted to see a release once in a while that made my programs faster/smaller/buggy without breaking any of them. -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
For the record, if we decide for a release soon, I'll make sure the new-typeable branch gets merged asap. Cheers, Pedro On Thu, Feb 7, 2013 at 8:25 AM, Simon Peyton-Jones simo...@microsoft.comwrote: Dear GHC users, * * *Carter*: Will this RTS update make it into ghc 7.8 update thats coming up in the next monthish? *Andreas*: We are almost there - we are now trying to sort out a problem on mac os x. It would be helpful to know if there is a cutoff date for getting things into 7.8. ** ** Simon, Ian, and I have just been discussing 7.8, and would be interested in what you guys think. At ICFP we speculated that we’d make a release of GHC soon after Christmas to embody tons of stuff that has been included since 7.6, specifically:*** * **· **major improvements in DPH (vectorisation avoidance, new vectoriser) **· **type holes **· **rebindable list syntax **· **major changes to the type inference engine **· **type level natural numbers **· **overlapping type families **· **the new code generator **· **support for vector (SSE/AVX) instructions ** ** Whenever it comes it would definitely be great to include Andreas friends’ work: **· **Scheduler changes to the RTS to improve latency ** ** The original major reason for proposing a post-Xmas release was to get DPH in a working state out into the wild. However, making a proper release imposes costs on everyone else. Library authors have to scurry around to make their libraries work, etc. Some of the new stuff hasn’t been in HEAD for that long, and hence has not been very thoroughly tested. (But of course making a release unleashes a huge wave of testing that doesn’t happen otherwise.) ** ** So another alternative is to leave it all as HEAD, and wait another few months before making a release. You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution. And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4. ** ** There seem to be pros and cons each way. I don’t have a strong opinion. If you have a view, let us know. ** ** Simon ** ** -- You received this message because you are subscribed to the Google Groups parallel-haskell group. To unsubscribe from this group and stop receiving emails from it, send an email to parallel-haskell+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
* Simon Peyton-Jones simo...@microsoft.com [2013-02-07 08:25:10+] So another alternative is to leave it all as HEAD, and wait another few months before making a release. You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution. And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4. Maybe make a release candidate, as was done with 7.6.2? Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
In practice the versions of GHC that are widely used are those that are included in the platform. Maybe we should coordinate with their next release? They are targeting a May 6 release, and the release process is starting March 4, so it sounds like the original GHC release plan (February release) would be a good fit for the platform as it would allow library writers to catch up and ensure that STABLE was tested enough for inclusion in the platform. It would be a shame to miss the platform release. Geoff On 02/07/2013 08:25 AM, Simon Peyton-Jones wrote: Dear GHC users, * * *Carter*: Will this RTS update make it into ghc 7.8 update thats coming up in the next monthish? *Andreas*: We are almost there - we are now trying to sort out a problem on mac os x. It would be helpful to know if there is a cutoff date for getting things into 7.8. Simon, Ian, and I have just been discussing 7.8, and would be interested in what you guys think. At ICFP we speculated that we’d make a release of GHC soon after Christmas to embody tons of stuff that has been included since 7.6, specifically: · major improvements in DPH (vectorisation avoidance, new vectoriser) · type holes · rebindable list syntax · major changes to the type inference engine · type level natural numbers · overlapping type families · the new code generator · support for vector (SSE/AVX) instructions Whenever it comes it would definitely be great to include Andreas friends’ work: · Scheduler changes to the RTS to improve latency The original major reason for proposing a post-Xmas release was to get DPH in a working state out into the wild. However, making a proper release imposes costs on everyone else. Library authors have to scurry around to make their libraries work, etc. Some of the new stuff hasn’t been in HEAD for that long, and hence has not been very thoroughly tested. (But of course making a release unleashes a huge wave of testing that doesn’t happen otherwise.) So another alternative is to leave it all as HEAD, and wait another few months before making a release. You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution. And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4. There seem to be pros and cons each way. I don’t have a strong opinion. If you have a view, let us know. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Geoff's reasoning seems quite sound. +1 for February release. On Feb 7, 2013, at 3:50 AM, Geoffrey Mainland mainl...@apeiron.net wrote: In practice the versions of GHC that are widely used are those that are included in the platform. Maybe we should coordinate with their next release? They are targeting a May 6 release, and the release process is starting March 4, so it sounds like the original GHC release plan (February release) would be a good fit for the platform as it would allow library writers to catch up and ensure that STABLE was tested enough for inclusion in the platform. It would be a shame to miss the platform release. Geoff On 02/07/2013 08:25 AM, Simon Peyton-Jones wrote: Dear GHC users, * * *Carter*: Will this RTS update make it into ghc 7.8 update thats coming up in the next monthish? *Andreas*: We are almost there - we are now trying to sort out a problem on mac os x. It would be helpful to know if there is a cutoff date for getting things into 7.8. Simon, Ian, and I have just been discussing 7.8, and would be interested in what you guys think. At ICFP we speculated that we’d make a release of GHC soon after Christmas to embody tons of stuff that has been included since 7.6, specifically: · major improvements in DPH (vectorisation avoidance, new vectoriser) · type holes · rebindable list syntax · major changes to the type inference engine · type level natural numbers · overlapping type families · the new code generator · support for vector (SSE/AVX) instructions Whenever it comes it would definitely be great to include Andreas friends’ work: · Scheduler changes to the RTS to improve latency The original major reason for proposing a post-Xmas release was to get DPH in a working state out into the wild. However, making a proper release imposes costs on everyone else. Library authors have to scurry around to make their libraries work, etc. Some of the new stuff hasn’t been in HEAD for that long, and hence has not been very thoroughly tested. (But of course making a release unleashes a huge wave of testing that doesn’t happen otherwise.) So another alternative is to leave it all as HEAD, and wait another few months before making a release. You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution. And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4. There seem to be pros and cons each way. I don’t have a strong opinion. If you have a view, let us know. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
I'm not too optimistic we could actually get the final release out during February, assuming we want to allow a couple of weeks for people to test an RC. Does the Haskell Platform actually want to commit to using a GHC release with tons of [new] stuff, that has had little testing, days or weeks after its release? I thought the idea was that it would favour known-good releases over the latest-and-greatest, but perhaps I misunderstood or the philosophy has changed. Thanks Ian On Thu, Feb 07, 2013 at 09:00:37AM -0500, Richard Eisenberg wrote: Geoff's reasoning seems quite sound. +1 for February release. On Feb 7, 2013, at 3:50 AM, Geoffrey Mainland mainl...@apeiron.net wrote: In practice the versions of GHC that are widely used are those that are included in the platform. Maybe we should coordinate with their next release? They are targeting a May 6 release, and the release process is starting March 4, so it sounds like the original GHC release plan (February release) would be a good fit for the platform as it would allow library writers to catch up and ensure that STABLE was tested enough for inclusion in the platform. It would be a shame to miss the platform release. Geoff On 02/07/2013 08:25 AM, Simon Peyton-Jones wrote: Dear GHC users, * * *Carter*: Will this RTS update make it into ghc 7.8 update thats coming up in the next monthish? *Andreas*: We are almost there - we are now trying to sort out a problem on mac os x. It would be helpful to know if there is a cutoff date for getting things into 7.8. Simon, Ian, and I have just been discussing 7.8, and would be interested in what you guys think. At ICFP we speculated that we’d make a release of GHC soon after Christmas to embody tons of stuff that has been included since 7.6, specifically: · major improvements in DPH (vectorisation avoidance, new vectoriser) · type holes · rebindable list syntax · major changes to the type inference engine · type level natural numbers · overlapping type families · the new code generator · support for vector (SSE/AVX) instructions Whenever it comes it would definitely be great to include Andreas friends’ work: · Scheduler changes to the RTS to improve latency The original major reason for proposing a post-Xmas release was to get DPH in a working state out into the wild. However, making a proper release imposes costs on everyone else. Library authors have to scurry around to make their libraries work, etc. Some of the new stuff hasn’t been in HEAD for that long, and hence has not been very thoroughly tested. (But of course making a release unleashes a huge wave of testing that doesn’t happen otherwise.) So another alternative is to leave it all as HEAD, and wait another few months before making a release. You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution. And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4. There seem to be pros and cons each way. I don’t have a strong opinion. If you have a view, let us know. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 7.8 release?
+1 Ph. -Original Message- From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- users-boun...@haskell.org] On Behalf Of Richard Eisenberg Sent: donderdag 7 februari 2013 15:01 To: Geoffrey Mainland Cc: parallel-hask...@googlegroups.com; glasgow-haskell-users@haskell.org; ghc-d...@haskell.org Subject: Re: GHC 7.8 release? Geoff's reasoning seems quite sound. +1 for February release. On Feb 7, 2013, at 3:50 AM, Geoffrey Mainland mainl...@apeiron.net wrote: In practice the versions of GHC that are widely used are those that are included in the platform. Maybe we should coordinate with their next release? They are targeting a May 6 release, and the release process is starting March 4, so it sounds like the original GHC release plan (February release) would be a good fit for the platform as it would allow library writers to catch up and ensure that STABLE was tested enough for inclusion in the platform. It would be a shame to miss the platform release. Geoff On 02/07/2013 08:25 AM, Simon Peyton-Jones wrote: Dear GHC users, * * *Carter*: Will this RTS update make it into ghc 7.8 update thats coming up in the next monthish? *Andreas*: We are almost there - we are now trying to sort out a problem on mac os x. It would be helpful to know if there is a cutoff date for getting things into 7.8. Simon, Ian, and I have just been discussing 7.8, and would be interested in what you guys think. At ICFP we speculated that we'd make a release of GHC soon after Christmas to embody tons of stuff that has been included since 7.6, specifically: * major improvements in DPH (vectorisation avoidance, new vectoriser) * type holes * rebindable list syntax * major changes to the type inference engine * type level natural numbers * overlapping type families * the new code generator * support for vector (SSE/AVX) instructions Whenever it comes it would definitely be great to include Andreas friends' work: * Scheduler changes to the RTS to improve latency The original major reason for proposing a post-Xmas release was to get DPH in a working state out into the wild. However, making a proper release imposes costs on everyone else. Library authors have to scurry around to make their libraries work, etc. Some of the new stuff hasn't been in HEAD for that long, and hence has not been very thoroughly tested. (But of course making a release unleashes a huge wave of testing that doesn't happen otherwise.) So another alternative is to leave it all as HEAD, and wait another few months before making a release. You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution. And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4. There seem to be pros and cons each way. I don't have a strong opinion. If you have a view, let us know. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
I agree with Ian. Mid-February is very soon, and there's a lot of stuff that seems to just be coming in now. That doesn't leave much time for testing to get 7.8 out in sync with the platform. Although my perspective is a bit colored by the last release. Testing the 7.6.1 RC took several weeks for us because of the number of upstream packages that needed to be updated (not all trivially). By the time we were prepared to begin testing our own systems 7.6.1 was already released, and we couldn't use it because of a number of bugs ( http://hackage.haskell.org/trac/ghc/ticket/7257 was a blocker, but there were others also). Most of the bugs were fixed very quickly (thanks Simon M. and Simon PJ!), but by then they were already in the wild. If there had been a bit more time to test 7.6.1, maybe some of those fixes would have made it into the release. John L. On Thu, Feb 7, 2013 at 10:23 PM, Ian Lynagh i...@well-typed.com wrote: I'm not too optimistic we could actually get the final release out during February, assuming we want to allow a couple of weeks for people to test an RC. Does the Haskell Platform actually want to commit to using a GHC release with tons of [new] stuff, that has had little testing, days or weeks after its release? I thought the idea was that it would favour known-good releases over the latest-and-greatest, but perhaps I misunderstood or the philosophy has changed. Thanks Ian On Thu, Feb 07, 2013 at 09:00:37AM -0500, Richard Eisenberg wrote: Geoff's reasoning seems quite sound. +1 for February release. On Feb 7, 2013, at 3:50 AM, Geoffrey Mainland mainl...@apeiron.net wrote: In practice the versions of GHC that are widely used are those that are included in the platform. Maybe we should coordinate with their next release? They are targeting a May 6 release, and the release process is starting March 4, so it sounds like the original GHC release plan (February release) would be a good fit for the platform as it would allow library writers to catch up and ensure that STABLE was tested enough for inclusion in the platform. It would be a shame to miss the platform release. Geoff On 02/07/2013 08:25 AM, Simon Peyton-Jones wrote: Dear GHC users, * * *Carter*: Will this RTS update make it into ghc 7.8 update thats coming up in the next monthish? *Andreas*: We are almost there - we are now trying to sort out a problem on mac os x. It would be helpful to know if there is a cutoff date for getting things into 7.8. Simon, Ian, and I have just been discussing 7.8, and would be interested in what you guys think. At ICFP we speculated that we’d make a release of GHC soon after Christmas to embody tons of stuff that has been included since 7.6, specifically: · major improvements in DPH (vectorisation avoidance, new vectoriser) · type holes · rebindable list syntax · major changes to the type inference engine · type level natural numbers · overlapping type families · the new code generator · support for vector (SSE/AVX) instructions Whenever it comes it would definitely be great to include Andreas friends’ work: · Scheduler changes to the RTS to improve latency The original major reason for proposing a post-Xmas release was to get DPH in a working state out into the wild. However, making a proper release imposes costs on everyone else. Library authors have to scurry around to make their libraries work, etc. Some of the new stuff hasn’t been in HEAD for that long, and hence has not been very thoroughly tested. (But of course making a release unleashes a huge wave of testing that doesn’t happen otherwise.) So another alternative is to leave it all as HEAD, and wait another few months before making a release. You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution. And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4. There seem to be pros and cons each way. I don’t have a strong opinion. If you have a view, let us know. Simon ___ Haskell-platform mailing list haskell-platf...@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 7.8 release?
It’s fairly simple in my mind. There are two “channels” (if I understand Mark’s terminology right): · Haskell Platform: o A stable development environment, lots of libraries known to work o Newcomers, and people who value stability, should use the Haskell Platform o HP comes with a particular version of GHC, probably not the hottest new one, but that doesn’t matter. It works. · GHC home page downloads: o More features but not so stable o Libraries not guaranteed to work o Worth releasing, though, as a forcing function to fix bugs, and as a checkpoint for people to test, so that by the time the HP adopts a particular version it is reasonably solid. So we already have the two channels Mark asks for, don’t we? One is called the Haskell Platform and one is called the GHC home page. That leaves a PR issue: we really don’t want newcomers or Joe Users wanting the “new shiny”. They want the Haskell Platform, and as Mark says those users should not pay the slightest attention until it appears in the Haskell Platform. So perhaps we principally need a way to point people away from GHC and towards HP? eg We could prominently say at every download point “Stop! Are you sure you want this? You might be better off with the Haskell Platform! Here’s why...”. Have I understood aright? If so, how could we achieve the right social dynamics? Our goal is to let people who value stability get stability, while the hot-shots race along in a different channel and pay the price of flat tires etc. PS: absolutely right to use 7.6.2 for the next HP. Don’t even think about 7.8. Simon From: Mark Lentczner [mailto:mark.lentcz...@gmail.com] Sent: 07 February 2013 17:43 To: Simon Peyton-Jones Cc: andreas.voel...@gmail.com; Carter Schonwald; GHC users; Simon Marlow; parallel-haskell; kosti...@gmail.com; Edsko de Vries; ghc-d...@haskell.org Subject: Re: GHC 7.8 release? I'd say the window for 7.8 in the platform is about closed. If 7.8 were to be release in the next two weeks that would be just about the least amount of time I'd want to see for libraries in the platform to get all stable with the GHC version. And we'd also be counting on the GHC team to be quickly responding to bugs so that there could be a point release of 7.8 mid-April. Historically, none of that seems likely. So my current trajectory is to base HP 2013.2.0.0 on GHC 7.6.2. Since 7.8 will seems like it will be released before May, we will be faced again with the bad public relations issue: Everyone will want the new shiny and be confused as to why the platform is such a laggard. We'll see four reactions: * New comers who are starting out and figure they should use the latest... Many will try to use 7.8, half the libraries on hackage won't work, things will be wonky, and they'll have a poor experience. * People doing production / project work will stay on 7.6 and ignore 7.8 for a few months. * The small group of people exploring the frontiers will know how to get things set up and be happy. * Eventually library authors will get around to making sure their stuff will work with it. I wish GHC would radically change it's release process. Things like 7.8 shouldn't be release as 7.8. That sounds major and stable. The web site will have 7.8 at the top. The warning to use the platform will fall flat because it makes the platform look out of date. Really, 7.8 should be in a different release channel, not on the front page. It should bake in that channel for six months - where only the third group of people will use it, until it is getting close to merge into main, at which point the fourth group will start to use it, so that the day it hits main, all the libraries just work. Ideally, the first two groups of people will not pay the slightest attention to it until it is further baked. While we achievements of the GHC team are great, less than half of those 7.8 features seem interesting from the viewpoint of the aims of the platform. I don't think adding syntactic or type-level features are really all that important for Haskell at this juncture. And while I do like to see improvements in generated code and run-time performance, I think even those are less important than making crucial ecosystem improvements to things like package management, cross-compilation, and libraries. - Mark ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Hi Simon, The download page already has a big Stop there. http://www.haskell.org/ghc/download_ghc_7_6_2 Apart from that, I am /really/ looking forward to sse/avx extensions and the official new-code-gen to further narrow the gap between high-performance C and high-performance Haskell. That being said, I would be fine using HEAD, but a release is very convenient in terms of installing, even if they are in the form of rc (which I typically install to see if something breaks or is faster). Maybe you want to consider providing a couple of release candidates instead of 7.8 now? Gruss, Christian * Simon Peyton Jones simo...@microsoft.com [07.02.2013 19:25]: It's fairly simple in my mind. There are two channels (if I understand Mark's terminology right): . Haskell Platform: o A stable development environment, lots of libraries known to work o Newcomers, and people who value stability, should use the Haskell Platform o HP comes with a particular version of GHC, probably not the hottest new one, but that doesn't matter. It works. . GHC home page downloads: o More features but not so stable o Libraries not guaranteed to work o Worth releasing, though, as a forcing function to fix bugs, and as a checkpoint for people to test, so that by the time the HP adopts a particular version it is reasonably solid. So we already have the two channels Mark asks for, don't we? One is called the Haskell Platform and one is called the GHC home page. That leaves a PR issue: we really don't want newcomers or Joe Users wanting the new shiny. They want the Haskell Platform, and as Mark says those users should not pay the slightest attention until it appears in the Haskell Platform. So perhaps we principally need a way to point people away from GHC and towards HP? eg We could prominently say at every download point Stop! Are you sure you want this? You might be better off with the Haskell Platform! Here's why Have I understood aright? If so, how could we achieve the right social dynamics? Our goal is to let people who value stability get stability, while the hot-shots race along in a different channel and pay the price of flat tires etc. PS: absolutely right to use 7.6.2 for the next HP. Don't even think about 7.8. Simon From: Mark Lentczner [mailto:mark.lentcz...@gmail.com] Sent: 07 February 2013 17:43 To: Simon Peyton-Jones Cc: andreas.voel...@gmail.com; Carter Schonwald; GHC users; Simon Marlow; parallel-haskell; kosti...@gmail.com; Edsko de Vries; ghc-d...@haskell.org Subject: Re: GHC 7.8 release? I'd say the window for 7.8 in the platform is about closed. If 7.8 were to be release in the next two weeks that would be just about the least amount of time I'd want to see for libraries in the platform to get all stable with the GHC version. And we'd also be counting on the GHC team to be quickly responding to bugs so that there could be a point release of 7.8 mid-April. Historically, none of that seems likely. So my current trajectory is to base HP 2013.2.0.0 on GHC 7.6.2. Since 7.8 will seems like it will be released before May, we will be faced again with the bad public relations issue: Everyone will want the new shiny and be confused as to why the platform is such a laggard. We'll see four reactions: o New comers who are starting out and figure they should use the latest... Many will try to use 7.8, half the libraries on hackage won't work, things will be wonky, and they'll have a poor experience. o People doing production / project work will stay on 7.6 and ignore 7.8 for a few months. o The small group of people exploring the frontiers will know how to get things set up and be happy. o Eventually library authors will get around to making sure their stuff will work with it. I wish GHC would radically change it's release process. Things like 7.8 shouldn't be release as 7.8. That sounds major and stable. The web site will have 7.8 at the top. The warning to use the platform will fall flat because it makes the platform look out of date. Really, 7.8 should be in a different release channel, not on the front page. It should bake in that channel for six months - where only the third group of people will use it, until it is getting close to merge into main, at which point the fourth group will start to use it, so that the day it hits main, all the libraries just work. Ideally, the first two groups of people will not pay the slightest attention to it until it is further baked. While we achievements of the GHC team are great, less than
Re: GHC 7.8 release?
Hi all, Ian Lynagh wrote: Does the Haskell Platform actually want to commit to using a GHC release with tons of [new] stuff, that has had little testing, days or weeks after its release? I thought the idea was that it would favour known-good releases over the latest-and-greatest, but perhaps I misunderstood or the philosophy has changed. From a teaching perspective, I'd hope the philosophy is still known-good releases. The Haskell platform is what we deploy on our teaching machines, and we really need to be able to trust that it will work very smoothly, or we'd risk losing lots of valuable teaching time and, even worse, putting lots of students off Haskell. (Getting students to appreciate Haskell is an upwards struggle at the best of times anyway.) Something like new run-time system features sounds like something that really ought to be tested very thoroughly before being integrated into the HP. So, for (general) teaching, at least, stability over new features any day. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham n...@cs.nott.ac.uk This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
This is a slight tangent but, I am always somewhat confused about the release schedule. When reading this, the basic decision seems to come down to when do we cut a release, taking into account factors like reliability/bugs/support/community/other stuff like that. So, IMO, perhaps one thing that's needed is a more formalized release schedule, with something like a merge window for 'big changes'? For example, many projects like LLVM and GCC have fairly fixed release windows, with an accompanying merge window several months before an official release. (The Linux kernel does this too, but they have a much shorter cycle.) If a large feature misses the merge window, it must go into the next release. Personally, I am not too worried about necessarily getting every new feature into a release, even if they're awesome (and they all are!) And while giving HP users the latest and greatest is great, they want stability more than anything, in my opinion. So I think they're fine with that too. What I am worried about is there being a good length of time where the features integrated have time to bake and see some polish, without a lot of interference. There are a lot of issues with this including how to deal with work that goes on in the mean time, etc. GHC also has far less manpower and a much different ratio of developer influence and 'spread' than any of the above projects. And we have to define what qualifies as 'big change.' But if the issue seems to be one of time, synchronization, and quality, perhaps we should think about whether or not a change like a more formalized schedule could help. I think making releases so people can find bugs is important. But that will always happen anyway, so I'd rather be a little cautious and wait this one out, than try to cram it. The new vectoriser only came in within the past ~48 hours, and SIMD was just pushed in the past week (and DPH will need SIMD support merged, too!) I think Feburary or even March is way, way too early for a solid release, and it's certainly too late for the HP anyway. I see little pain in postponement, personally. On Thu, Feb 7, 2013 at 2:25 AM, Simon Peyton-Jones simo...@microsoft.com wrote: Dear GHC users, Carter: Will this RTS update make it into ghc 7.8 update thats coming up in the next monthish? Andreas: We are almost there - we are now trying to sort out a problem on mac os x. It would be helpful to know if there is a cutoff date for getting things into 7.8. Simon, Ian, and I have just been discussing 7.8, and would be interested in what you guys think. At ICFP we speculated that we’d make a release of GHC soon after Christmas to embody tons of stuff that has been included since 7.6, specifically: · major improvements in DPH (vectorisation avoidance, new vectoriser) · type holes · rebindable list syntax · major changes to the type inference engine · type level natural numbers · overlapping type families · the new code generator · support for vector (SSE/AVX) instructions Whenever it comes it would definitely be great to include Andreas friends’ work: · Scheduler changes to the RTS to improve latency The original major reason for proposing a post-Xmas release was to get DPH in a working state out into the wild. However, making a proper release imposes costs on everyone else. Library authors have to scurry around to make their libraries work, etc. Some of the new stuff hasn’t been in HEAD for that long, and hence has not been very thoroughly tested. (But of course making a release unleashes a huge wave of testing that doesn’t happen otherwise.) So another alternative is to leave it all as HEAD, and wait another few months before making a release. You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution. And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4. There seem to be pros and cons each way. I don’t have a strong opinion. If you have a view, let us know. Simon ___ ghc-devs mailing list ghc-d...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- Regards, Austin ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On 08/02/2013, at 5:15 AM, Simon Peyton-Jones wrote: So perhaps we principally need a way to point people away from GHC and towards HP? eg We could prominently say at every download point “Stop! Are you sure you want this? You might be better off with the Haskell Platform! Here’s why...”. Right now, the latest packages uploaded to Hackage get built with ghc-7.6 (only), and all the pages say Built on ghc-7.6. By doing this we force *all* library developers to run GHC 7.6. I think this sends the clearest message about what the real GHC version is. We'd have more chance of turning Joe User off the latest GHC release if Hackage was clearly split into stable/testing channels. Linux distros have been doing this for years. Ben. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Thu, Feb 7, 2013 at 6:48 PM, Ben Lippmeier b...@ouroborus.net wrote: Right now, the latest packages uploaded to Hackage get built with ghc-7.6 (only), and all the pages say Built on ghc-7.6. By doing this we force *all* library developers to run GHC 7.6. I think this sends the clearest message about what the real GHC version is. I don't know how closely users look at the built on line on the package page. Perhaps they look there, perhaps they don't. Between Bryan and me we build all of our own packages and all HP packages on the latest 3 GHC versions: http://ci.johantibell.com/ https://jenkins.serpentine.com/ That doesn't mean that it would be a bad idea to build all Hackage packages on using more GHC versions, but that won't happen until the Hackage project is unstuck (it has been stuck for years!). -- Johan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
johan, how do you and Bryan have those jenkin's nodes setup? (I'm planning to setup something similar for my own use, and seeing how thats setup would be awesome) thanks -Carter On Thu, Feb 7, 2013 at 10:55 PM, Johan Tibell johan.tib...@gmail.comwrote: On Thu, Feb 7, 2013 at 6:48 PM, Ben Lippmeier b...@ouroborus.net wrote: Right now, the latest packages uploaded to Hackage get built with ghc-7.6 (only), and all the pages say Built on ghc-7.6. By doing this we force *all* library developers to run GHC 7.6. I think this sends the clearest message about what the real GHC version is. I don't know how closely users look at the built on line on the package page. Perhaps they look there, perhaps they don't. Between Bryan and me we build all of our own packages and all HP packages on the latest 3 GHC versions: http://ci.johantibell.com/ https://jenkins.serpentine.com/ That doesn't mean that it would be a bad idea to build all Hackage packages on using more GHC versions, but that won't happen until the Hackage project is unstuck (it has been stuck for years!). -- Johan -- You received this message because you are subscribed to the Google Groups parallel-haskell group. To unsubscribe from this group and stop receiving emails from it, send an email to parallel-haskell+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
johan, how do you and Bryan have those jenkin's nodes setup? (I'm planning to setup something similar for my own use, and seeing how thats setup would be awesome) thanks -Carter On Thu, Feb 7, 2013 at 10:55 PM, Johan Tibell johan.tib...@gmail.comwrote: On Thu, Feb 7, 2013 at 6:48 PM, Ben Lippmeier b...@ouroborus.net wrote: Right now, the latest packages uploaded to Hackage get built with ghc-7.6 (only), and all the pages say Built on ghc-7.6. By doing this we force *all* library developers to run GHC 7.6. I think this sends the clearest message about what the real GHC version is. I don't know how closely users look at the built on line on the package page. Perhaps they look there, perhaps they don't. Between Bryan and me we build all of our own packages and all HP packages on the latest 3 GHC versions: http://ci.johantibell.com/ https://jenkins.serpentine.com/ That doesn't mean that it would be a bad idea to build all Hackage packages on using more GHC versions, but that won't happen until the Hackage project is unstuck (it has been stuck for years!). -- Johan -- You received this message because you are subscribed to the Google Groups parallel-haskell group. To unsubscribe from this group and stop receiving emails from it, send an email to parallel-haskell+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users