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 <marlowsd@gmail.com> wrote:

> 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