Re: libpng-1.6.44 signed and released

John Bowler <[email protected]> Fri, 13 Sep 2024 15:09:06 -0700
Newsgroups gmane.comp.graphics.png.devel
Message-ID <CAP7U399PvPsfKGwDP-766m8r-VssjazbmLTRM8aSDU7D6iR2wA@mail.gmail.com>
--===============1024344333132763715==
Content-Type: multipart/alternative; boundary="0000000000006f9cef06220779af"

--0000000000006f9cef06220779af
Content-Type: text/plain; charset="UTF-8"

>There are still pull requests waiting in line, some of which are highly
useful, yet hard to apply to the libpng16 branch without risking breakage
in rather obscure areas of compatibility with existing build workflows.

There are also a number of "issues" (github-speak) which I've been fairly
dismissive of on github partly because a fix requires an API change.  Given
libpng 1.8 I can make changes (at least one of them as suggested in the
original issue) to fix these and potentially remove a number of annoying
bugs.  We also get to remove "deprecated" functions many of which are still
in use and, indeed, improve the PNG_DEPRECATED macro to include a more
explicit message about what is going to happen :-)

Still, as discussed on github, this is not yet libpng-ng (think libpng 1.7
without the compatibility requirement :-); feature and API compatibility
with the aim being to remove long term support requirements both in terms
of APIs and required build systems.  (Minimum compiler requirements, for
example, are something I consider well worth discussion.)

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

<div dir=3D"ltr"><div dir=3D"ltr">&gt;There are still pull requests waiting=
 in line, some of which are highly useful, yet hard to apply to the libpng1=
6 branch without risking breakage in rather obscure areas of compatibility =
with existing build workflows.</div><div dir=3D"ltr"><br></div><div>There a=
re also a number of &quot;issues&quot; (github-speak) which I&#39;ve been f=
airly dismissive of on github partly because a fix requires an API change.=
=C2=A0 Given libpng 1.8 I can make changes (at least one of them as suggest=
ed in the original issue) to fix these and potentially remove a number of a=
nnoying bugs.=C2=A0 We also get to remove &quot;deprecated&quot; functions =
many of which are still in use and, indeed, improve the PNG_DEPRECATED macr=
o to include a more explicit message about what is going to happen :-)</div=
><div><br></div><div>Still, as discussed on github, this is not yet libpng-=
ng (think libpng 1.7 without the compatibility requirement :-); feature and=
 API compatibility with the aim being to remove long term support requireme=
nts both in terms of APIs and required build systems.=C2=A0 (Minimum compil=
er requirements, for example, are something I consider well worth discussio=
n.)</div></div>

--0000000000006f9cef06220779af--


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


--===============1024344333132763715==
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

--===============1024344333132763715==--