Re: libpng version 2.0, anyone?

--===============0192948367744628092==
Content-Type: multipart/alternative; boundary="00000000000021cc5c06235e1a1b"

--00000000000021cc5c06235e1a1b
Content-Type: text/plain; charset="UTF-8"

>
> Any thoughts?
>

Numbers are cheap.  It doesn't mean they can't be meaningful.

So far the definitions have worked sort-of.  I'll use Vincent's use of
"major.minor" but I don't ascribe such significance to the words.  As
Cosmin seems to observe we have been stuck with "1".  Stuck at first base
as my fellow countrymen say.

The 1.x would have worked if they were a *fixed* ABI with a *fixed* API.
However over time the tendency emerged to fix bugs by adding ABIs and the
corresponding API.  That doesn't work because an ABI has to be fixed to
allow distribution of binaries; a binary ABI guarantees compile-once, use
anywhere.  The ABI might have bugs, even security level bugs, in some
versions but the app which uses it need not care because, gee, if the user
didn't fix their system they keep the bug!  Unfortunately with libpng if
you try that your app crashes.  So ABIs need to be fixed at some level.
This is what I believe was always intended by, in Vincent's terms, a
"minor" release.  ABI fixed, won't change until the next minor release.

If this is made true minor releases become functional, useful and
productive.  In a "minor" release the ABI changes, the API expands, maybe
changes a little, but adapting to it is pretty much a set of "minor" code
changes for app writers.  Indeed, since numbers are free, a minor release
can just be an ABI change with no meaningful API change; where the ABI
change is hidden by function-like macros.

But that doesn't mean we may not dream.  Maybe there will be libpng-2.0.

John Bowler <jbowler @ acm.org>

--00000000000021cc5c06235e1a1b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div>Any thoughts?</div></div></blockqu=
ote><div><br></div><div>Numbers are cheap.=C2=A0 It doesn&#39;t mean they c=
an&#39;t be meaningful.</div><div><br></div><div>So far the definitions hav=
e worked sort-of.=C2=A0 I&#39;ll use Vincent&#39;s use of &quot;major.minor=
&quot; but I don&#39;t ascribe such significance to the words.=C2=A0 As Cos=
min seems to observe we have been stuck with &quot;1&quot;.=C2=A0 Stuck at =
first base as my fellow countrymen say.</div><div><br></div><div>The 1.x wo=
uld have worked if they were a *fixed* ABI with a *fixed* API.=C2=A0 Howeve=
r over time the tendency emerged to fix bugs by adding ABIs and the corresp=
onding API.=C2=A0 That doesn&#39;t work because an ABI has to be fixed to a=
llow distribution of binaries; a binary ABI guarantees compile-once, use an=
ywhere.=C2=A0 The ABI might have bugs, even security level bugs, in some ve=
rsions but the app which uses it need not care because, gee, if the user di=
dn&#39;t fix their system they keep the bug!=C2=A0 Unfortunately with libpn=
g if you try that your app crashes.=C2=A0 So ABIs need to be fixed at some =
level.=C2=A0 This is what I believe was always intended by, in Vincent&#39;=
s terms, a &quot;minor&quot; release.=C2=A0 ABI fixed, won&#39;t change unt=
il the next minor release.</div><div><br></div><div>If this is made true mi=
nor releases become functional, useful and productive.=C2=A0 In a &quot;min=
or&quot; release the ABI changes, the API expands, maybe changes a little, =
but adapting to it is pretty much a set of &quot;minor&quot; code changes f=
or app writers.=C2=A0 Indeed, since numbers are free, a minor release can j=
ust be an ABI change with no meaningful API change; where the ABI change is=
 hidden by function-like macros.</div><div><br></div><div>But that doesn&#3=
9;t mean we may not dream.=C2=A0 Maybe there will be libpng-2.0.</div><div>=
<br></div><div>John Bowler &lt;jbowler=C2=A0@ <a href=3D"http://acm.org">ac=
m.org</a>&gt;</div></div></div>

--00000000000021cc5c06235e1a1b--


--===============0192948367744628092==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============0192948367744628092==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
png-mng-implement mailing list
png-mng-implement-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/png-mng-implement

--===============0192948367744628092==--