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">>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 "issues" (github-speak) which I'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 "deprecated" 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==--