Re: Proposal: Change to library proposal process
On 06 Jan 2011 11:32:45 +0000, Simon Marlow
The changes being proposed by Greg and Johan, as I understand it, would amount to the following. I'm willing to give it a try; we can always go back if it doesn't work out.
- maintainers are empowered to make API changes.
- no formal review process for API changes, although there is an expectation that non-trivial changes would still be discussed on the list beforehand.
From my experience upgrading Gentoo's Haskell distribution, I would like to suggest a bit more structure than this. API changes can wreak havoc with many packages. Therefore, I believe that we should _strongly_encourage_ upward compatibility in API changes.
This doesn't require that APIs remain static, nor need it cause a lot of difficulty for maintainers, if we _encourage_ smooth migration to the new API. One possible approach would be to add conditional compilation directives so the new and old APIs can co-exist initially. This would provide an easy workaround for packages that depend on the old API. There may be better methods than this, but this is always an option. Alternatively, we should try to develop adapter libraries (e.g., old-time and old-locale) so old code can still be compiled with minimal modification. There are still many packages that depend on base-3 and the switch to ghc-7.0 and base-4.3 breaks them. From the perspective of an enterprise developer the current situation is a show-stopper. In order to gain more enterprise penetration we need to make upgrades less painful. Cheers, Howard
Speaking as such a developer, I agree with Howard: can we please strongly
encourage upwards compatibility in API changes and well-documented migration
paths when this is not practical.
I was somewhat surprised to see maintainers being given carte blanche to
break APIs, package-maintainers and developers not always having the same
interests.
It could take only a few package maintainers to get it wrong over several
revisions and Hackage and maybe Haskell Platform could get a reputation for
instability.
Is it understood that any changes that could break code must break the code
statically?
Chris
From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org]
On Behalf Of Howard B. Golden
Sent: 06 January 2011 17:36
To: libraries@haskell.org; marlowsd@gmail.com
Subject: Re: Proposal: Change to library proposal process
On 06 Jan 2011 11:32:45 +0000, Simon Marlow
The changes being proposed by Greg and Johan, as I understand it, would amount to the following. I'm willing to give it a try; we can always go back if it doesn't work out.
- maintainers are empowered to make API changes.
- no formal review process for API changes, although there is an expectation that non-trivial changes would still be discussed on the list beforehand.
From my experience upgrading Gentoo's Haskell distribution, I would like to suggest a bit more structure than this. API changes can wreak havoc with many packages. Therefore, I believe that we should _strongly_encourage_ upward compatibility in API changes.
This doesn't require that APIs remain static, nor need it cause a lot of difficulty for maintainers, if we _encourage_ smooth migration to the new API. One possible approach would be to add conditional compilation directives so the new and old APIs can co-exist initially. This would provide an easy workaround for packages that depend on the old API. There may be better methods than this, but this is always an option. Alternatively, we should try to develop adapter libraries (e.g., old-time and old-locale) so old code can still be compiled with minimal modification. There are still many packages that depend on base-3 and the switch to ghc-7.0 and base-4.3 breaks them. From the perspective of an enterprise developer the current situation is a show-stopper. In order to gain more enterprise penetration we need to make upgrades less painful. Cheers, Howard _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3362 - Release Date: 01/05/11
On 1/6/11 3:11 PM, Chris Dornan wrote:
Speaking as such a developer, I agree with Howard: can we please strongly encourage upwards compatibility in API changes and well-documented migration paths when this is not practical.
I was somewhat surprised to see maintainers being given carte blanche to break APIs, package-maintainers and developers not always having the same interests.
Speaking only for myself, I think there is definite need for a carte blanche--- but we may only need one (or a few) instead of an endless supply of them. Namely, there is definite need for the wholesale revision being discussed elsewhere; and in order to have free reign for the big bang changes, it needs a carte. However, I agree that as a general model of maintaining core libraries, these cartes should be in short supply in order to accommodate those who require stability. Not long ago (circa GHC-6.8) there was much instability and that put a lot of folks off. While upwards compatibility is desirable when at all possible, there must be enough room for people to make breaking changes when necessary. Even folks working on kernels, distros, and enterprisey things recognize this need. The only issue to be resolved is how to make such changes in an orderly fashion. -- Live well, ~wren
I quite agree. I too would very much like to see a new set of cleaned-up libraries, freed from the need to slavishly maintain upwards compatibility with the current libraries, warts and all. My problem was with issuing a general carte blanche allowing any package maintainer to break an API without discussion. Chris From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of wren ng thornton Sent: 08 January 2011 07:32 To: libraries@haskell.org Subject: Re: Proposal: Change to library proposal process On 1/6/11 3:11 PM, Chris Dornan wrote:
Speaking as such a developer, I agree with Howard: can we please strongly encourage upwards compatibility in API changes and well-documented migration paths when this is not practical.
I was somewhat surprised to see maintainers being given carte blanche to break APIs, package-maintainers and developers not always having the same interests.
Speaking only for myself, I think there is definite need for a carte blanche--- but we may only need one (or a few) instead of an endless supply of them. Namely, there is definite need for the wholesale revision being discussed elsewhere; and in order to have free reign for the big bang changes, it needs a carte. However, I agree that as a general model of maintaining core libraries, these cartes should be in short supply in order to accommodate those who require stability. Not long ago (circa GHC-6.8) there was much instability and that put a lot of folks off. While upwards compatibility is desirable when at all possible, there must be enough room for people to make breaking changes when necessary. Even folks working on kernels, distros, and enterprisey things recognize this need. The only issue to be resolved is how to make such changes in an orderly fashion. -- Live well, ~wren _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3365 - Release Date: 01/07/11
participants (3)
-
Chris Dornan -
Howard B. Golden -
wren ng thornton