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
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
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,
*
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
On Sun, Feb 10, 2013 at 06:35:25PM +0800, Magicloud Magiclouds wrote:
Linuxmint Nadia, ghc-7.6.1 was built and running OK.
Just downloaded ghc-7.6.2, without changing anything and environment, and
boot and configure returned OK, I got these. What happened?
/usr/local/bin/ghc -H32m -O
(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
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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo
