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.

On Mon, Feb 11, 2013 at 5:03 PM, 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? 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

On Mon, Feb 11, 2013 at 6:37 PM, Johan Tibell wrote:

On Mon, Feb 11, 2013 at 4:34 PM, Gabriel Dos Reis 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

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