No subject


Tue Nov 30 21:47:11 CET 2010


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 at 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


------=_NextPart_000_004F_01CBADDD.E0EB5D50
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><!--[if !mso]><style>v\:* =
{behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><title>Re: Proposal: Change to library proposal =
process</title><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
p.avgcert, li.avgcert, div.avgcert
	{mso-style-name:avgcert;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-GB link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>Speaking as such a developer, &nbsp;I agree with Howard: can we =
please strongly encourage upwards compatibility in API changes and =
well-documented migration paths when this is not practical. =
<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>I was somewhat surprised to see maintainers being given carte blanche =
to break APIs, package-maintainers and developers not always having the =
same interests.<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>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.<o:p></o:p></span></p><p =
class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>Is it understood that any changes that could break code must break =
the code statically?<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>Chris<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><o:p>&nbsp;</o:p></span></p><div><div =
style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'><p class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>=
</b><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> =
libraries-bounces at haskell.org [mailto:libraries-bounces at haskell.org] =
<b>On Behalf Of </b>Howard B. Golden<br><b>Sent:</b> 06 January 2011 =
17:36<br><b>To:</b> libraries at haskell.org; =
marlowsd at gmail.com<br><b>Subject:</b> Re: Proposal: Change to library =
proposal process<o:p></o:p></span></p></div></div><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p><span =
style=3D'font-size:10.0pt'>On 06 Jan 2011 11:32:45 +0000, Simon Marlow =
&lt;<a href=3D"mailto:marlowsd at gmail.com">marlowsd at gmail.com</a>&gt; =
wrote:<br><br>&gt; The changes being proposed by Greg and Johan, as I =
understand it, would<br>&gt; amount to the following.&nbsp; I'm willing =
to give it a try; we can always go<br>&gt; back if it doesn't work =
out.<br>&gt;<br>&gt;&nbsp; - maintainers are empowered to make API =
changes.<br>&gt;<br>&gt;&nbsp; - no formal review process for API =
changes, although there is an<br>&gt;&nbsp;&nbsp;&nbsp; expectation that =
non-trivial changes would still be discussed =
on<br>&gt;&nbsp;&nbsp;&nbsp; the list beforehand.<br><br>From my =
experience upgrading Gentoo's Haskell distribution, I would like =
to<br>suggest a bit more structure than this. API changes can wreak =
havoc with many<br>packages. Therefore, I believe that we should =
_strongly_encourage_ upward<br>compatibility in API changes.<br><br>This =
doesn't require that APIs remain static, nor need it cause a lot =
of<br>difficulty for maintainers, if we _encourage_ smooth migration to =
the new API.<br>One possible approach would be to add conditional =
compilation directives so the<br>new and old APIs can co-exist =
initially. This would provide an easy workaround<br>for packages that =
depend on the old API. There may be better methods than this,<br>but =
this is always an option. Alternatively, we should try to develop =
adapter<br>libraries (e.g., old-time and old-locale) so old code can =
still be compiled with<br>minimal modification.<br><br>There are still =
many packages that depend on base-3 and the switch to ghc-7.0<br>and =
base-4.3 breaks them. From the perspective of an enterprise developer =
the<br>current situation is a show-stopper. In order to gain more =
enterprise<br>penetration we need to make upgrades less =
painful.<br><br>Cheers,<br><br>Howard<br><br><br>________________________=
_______________________<br>Libraries mailing list<br><a =
href=3D"mailto:Libraries at haskell.org">Libraries at haskell.org</a><br><a =
href=3D"http://www.haskell.org/mailman/listinfo/libraries">http://www.has=
kell.org/mailman/listinfo/libraries</a></span> <o:p></o:p></p><div =
class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><hr =
size=3D1 width=3D"100%" noshade style=3D'color:#A0A0A0' =
align=3Dcenter></div><p class=3Davgcert>No virus found in this =
message.<br>Checked by AVG - <a =
href=3D"http://www.avg.com">www.avg.com</a><br>Version: 10.0.1191 / =
Virus Database: 1435/3362 - Release Date: =
01/05/11<o:p></o:p></p></div></body></html>
------=_NextPart_000_004F_01CBADDD.E0EB5D50--




More information about the Libraries mailing list