Re: libpng version 2.0, anyone?
Andrew Randrianasulu <[email protected]> Thu, 19 Sep 2024 21:36:38 +0300
| Newsgroups | gmane.comp.graphics.png.devel |
|---|---|
| Message-ID | <CA+rFky7ghkz4BPCau51cLaCS_qiT1Rke0RJVEgP8REzj3RoQjw@mail.gmail.com> |
--===============4638535834494603451== Content-Type: multipart/alternative; boundary="000000000000c95caf06227d347a" --000000000000c95caf06227d347a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D1=87=D1=82, 19 =D1=81=D0=B5=D0=BD=D1=82. 2024 =D0=B3., 21:06 Cosmin Truta= <[email protected]>: > *## EXECUTIVE SUMMARY* > > What's DONE: > * libpng 1.6.44 was released. > * The "libpng18" branch for libpng-1.8.0 was created. > * The "contrib/oss-fuzz" directory was deleted. > > What TO DO: > * Release libpng 1.6.45. > * Create a new branch for libpng-2.0. > * Discard implementation quirks and cruft where possible. > * Implement all PNG features that are currently missing. > But what exactly is missing? Animated pngs? Also, I found draft of IEC61966-2-1 somewhere along libpng historical documents, but it really was very early draft. Can anyone email me non-draft version? :) * Embrace new C standard features where feasible. > * Adopt Semantic Versioning (i.e., "SemVer"). > * Publish a new repository named "pngfuzz". > > What NOT TO DO: > * Modernize the libpng API. > * Gratuitously break compatibility with compilers in use. > * Gratuitously break the world of PNG-supporting apps. > > *## INTRODUCTION* > > Hello, everyone, > > Among the many traditions that our little group has been having, one of > those is to fork version branches and then abandon them. So far we've had > "libpng13" and "libpng17". Coming up next, a branch that I haven't even > formally announced yet and I already want to close. > > The elusive version 2.0 of libpng has been mentioned occasionally, ever > since I joined the group in early 2000. ("This is what libpng will be whe= n > we break the API compatibility with libpng 1.x.") But: here comes braggin= g: > > I've seen on various forums, every now and then, people saying VERY good > things about how stable libpng is, and how reliable and drama-free its > upgrades are, so yeah, go ahead, do upgrade. (Rest In Peace, Glenn.) On t= he > other hand, the cost of maintaining the drama-free-ness in the present-da= y > libpng v1.6.x for the benefit of its users has become increasingly high f= or > us developers. In order not to break ABI compatibility and build workflow= s > and stuff, we kept on walking on a minefield. Yes, we did a good job, > but... the time to retire libpng 1.6.x, and continue supporting it in > maintenance mode only, has finally arrived. > > > *## ANNOUNCING libpng 1.8.0... umm... libpng 2.0* > The "libpng18" branch is here: > https://github.com/pnggroup/libpng/tree/libpng18 > > John Bowler and other contributors have already submitted pull requests > (thank you), and I have yet to apply them (will do). It seemed like we we= re > headed rather well towards version 1.8.0, but without really knowing why > 1.8.0. Here are two questions: > > ***What happens to the public DLL and SO library names?*** > > Naturally, libpng16.dll will be followed by libpng18.dll and libpng18.a > and libpng18.so.18, and so on. > Then comes libpng19, then libpng110 (not libpng20), then... ... ... > > And yet... shouldn't libpng18.dll be used for libpng version 18.0.0, and > not for 1.8.0? > > ***Why do we still insist on not moving past libpng-1.x?*** > > Here's my advice: anyone who wants to build a brand and grand and new > library from scratch should first and foremost read *"Things You Should > Never Do, Part One"* by Joel Spolsky. And then, proceed on doing it, with > a new name, like, I don't know, "libpng-ng", or "libpng-plus", or > "libpng-plusplus", or "libpng-minusminus", or "libpng-rusty", etc. etc. I= f > it works out -- great. And if it doesn't -- here's one helluva piece of > lesson to learn from Spolsky's article: > > *"Luckily [...] they had never stopped working on the old code base, so > they had something to ship, making it merely a financial disaster, not a > strategic one."* > > So: > > Just as PNG itself is designed to be extensible without breaking > compatibility, libpng should, also, be extensible without breaking > compatibility. That doesn't mean we cannot delete long-forgotten API > functions that nobody's using anymore, because we absolutely can, and we > absolutely should. However, even more importantly, that DOES mean we MUST > NOT pull the API rug from underneath the apps that are still alive and > kicking. > > *## CONCLUSION* > > Here comes libpng version 2: just like libpng version 1.6, newer, better, > more feature-complete, and also, VERY IMPORTANTLY, with a drama-free > upgrade that should be no different from what we had from libpng 1.0 to > 1.2, or from libpng 1.5 to 1.6. > > We should never stop working on the old libpng codebase, but rather, we > should modernize it whenever the opportunity presents itself, such as, fo= r > example, here and now. > > For the compiled library names, I propose libpng2.dll (on Windows), > libpng.2.dylib and libpng.2.0.dylib (on Mac), libpng.so.2 and libpng.so.2= .0 > (elsewhere on Unix). New features added? Upgrade to libpng-2.1. A > patchlevel release to v2.1, with no new features added? Upgrade to > libpng-2.1.1. More patchlevel releases, security fixes, etc? Upgrade to > libpng-2.1.2, libpng-2.1.3, etc. Keep going until the next new PNG featur= e > support comes in libpng, when it's time to upgrade to libpng-2.2. The > compiled library name remains unchanged, i.e. libpng2.dll and > libpng.2.dylib and libpng.so.2. > > ... until we break ABI compatibility again for some reason, just as we di= d > it less than a handful of times in more than a quarter-century. That woul= d > be the time for us to move up to libpng-3.0 and libpng3.dll, etc. And so = on > and so forth, to libpng-4.0 and libpng4.dll etc., etc. > > Let us not forget to skip far-in-the-future libpng versions entirely, suc= h > us libpng version 10.0, and also version 12.0, and also version 14.0 and > 15.0 and 16.0. I would suggest transitioning from version 8.x to version > 9.0, and then, from version 9.x to version 20.0, and then, from version > 20.x to version 21.0; but that should be another story for another centur= y. > > *## NEXT STEPS* > > For the immediate future, we will continue business-as-usual with our > current development branches "libpng16" and "libpng18". I will continue > adding changes to "libpng18" then cherry-pick them into "libpng16" as > appropriate. Then publish libpng-1.6.45. Then fork off the branch for > libpng-2.0. > > Suggestions (on any topic) are welcome. > > *## QUESTIONS?* > > ;-) > > Sincerely, > Cosmin > > _______________________________________________ > png-mng-implement mailing list > png-mng-implement-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org > https://lists.sourceforge.net/lists/listinfo/png-mng-implement > --000000000000c95caf06227d347a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">=D1=87=D1=82, 19 =D1=81=D0=B5=D0=BD=D1=82. 2024 =D0=B3= ., 21:06 Cosmin Truta <<a href=3D"mailto:[email protected]" target=3D"_bl= ank" rel=3D"noreferrer">[email protected]</a>>:<br></div><blockquote clas= s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad= ding-left:1ex"><div dir=3D"ltr"><font size=3D"4"><b>## EXECUTIVE SUMMARY</b= ></font><br><br>What's DONE:<br>=C2=A0* libpng 1.6.44 was released.<br>= =C2=A0* The "libpng18" branch for libpng-1.8.0 was created.<br>= =C2=A0* The "contrib/oss-fuzz" directory was deleted.<br><br>What= TO DO:<br>=C2=A0* Release libpng 1.6.45.<br>=C2=A0* Create a new branch fo= r libpng-2.0.<br>=C2=A0* Discard implementation quirks and cruft where poss= ible.<br>=C2=A0* Implement all PNG features that are currently missing.<br>= </div></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto= ">But what exactly is missing? Animated pngs?</div><div dir=3D"auto"><br></= div><div dir=3D"auto">Also, I found draft of=C2=A0IEC61966-2-1=C2=A0 =C2=A0= somewhere along libpng historical documents, but it really was very early d= raft. Can anyone email me non-draft version? :)</div><div dir=3D"auto"><br>= </div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"a= uto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"= margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"= ltr">=C2=A0* Embrace new C standard features where feasible.<br>=C2=A0* Ado= pt Semantic Versioning (i.e., "SemVer").<br>=C2=A0* Publish a new= repository named "pngfuzz".<br><br>What NOT TO DO:<br>=C2=A0* Mo= dernize the libpng API.<br>=C2=A0* Gratuitously break compatibility with co= mpilers in use.<br>=C2=A0* Gratuitously break the world of PNG-supporting a= pps.<br><br><font size=3D"4"><b>## INTRODUCTION</b></font><br><br>Hello, ev= eryone,<br><br>Among the many traditions that our little group has been hav= ing, one of those is to fork version branches and then abandon them. So far= we've had "libpng13" and "libpng17". Coming up nex= t, a branch that I haven't even formally announced yet and I already wa= nt to close.<br><br>The elusive version 2.0 of libpng has been mentioned oc= casionally, ever since I joined the group in early 2000. ("This is wha= t libpng will be when we break the API compatibility with libpng 1.x."= ) But: here comes bragging:<br><br>I've seen on various forums, every n= ow and then, people saying VERY good things about how stable libpng is, and= how reliable and drama-free its upgrades are, so yeah, go ahead, do upgrad= e. (Rest In Peace, Glenn.) On the other hand, the cost of maintaining the d= rama-free-ness in the present-day libpng v1.6.x for the benefit of its user= s has become increasingly high for us developers. In order not to break ABI= compatibility and build workflows and stuff, we kept on walking on a minef= ield. Yes, we did a good job, but... the time to retire libpng 1.6.x, and c= ontinue supporting it in maintenance mode only, has finally arrived.<br><br= ><b><font size=3D"4">## ANNOUNCING libpng 1.8.0... umm... libpng 2.0</font>= <br></b><br>The "libpng18" branch is here:<br><a href=3D"https://= github.com/pnggroup/libpng/tree/libpng18" rel=3D"noreferrer noreferrer" tar= get=3D"_blank">https://github.com/pnggroup/libpng/tree/libpng18</a><br><br>= John Bowler and other contributors have already submitted pull requests (th= ank you), and I have yet to apply them (will do). It seemed like we were he= aded rather well towards version 1.8.0, but without really knowing why 1.8.= 0. Here are two questions:<br><br><b>**What happens to the public DLL and S= O library names?**</b><br><br>Naturally, libpng16.dll will be followed by l= ibpng18.dll and libpng18.a and libpng18.so.18, and so on.<br>Then comes lib= png19, then libpng110 (not libpng20), then... ... ...<br><br>And yet... sho= uldn't libpng18.dll be used for libpng version 18.0.0, and not for 1.8.= 0?<br><div><br></div><div><b>**Why do we still insist on not moving past li= bpng-1.x?**</b><br></div><div><br></div>Here's my advice: anyone who wa= nts to build a brand and grand and new library from scratch should first an= d foremost read <i><span style=3D"font-family:georgia,serif;color:rgb(255,0= ,0)">"Things You Should Never Do, Part One"</span></i> by Joel Sp= olsky. And then, proceed on doing it, with a new name, like, I don't kn= ow, "libpng-ng", or "libpng-plus", or "libpng-plus= plus", or "libpng-minusminus", or "libpng-rusty", = etc. etc. If it works out -- great. And if it doesn't -- here's one= helluva piece of lesson to learn from Spolsky's article:<br><br><span = style=3D"color:rgb(255,0,0)"><i><span style=3D"font-family:georgia,serif">&= quot;Luckily [...] they had never stopped working on the old code base, so = they had something to ship, making it merely a financial disaster, not a st= rategic one."</span></i></span><br><br>So:<br><br>Just as PNG itself i= s designed to be extensible without breaking compatibility, libpng should, = also, be extensible without breaking compatibility. That doesn't mean w= e cannot delete long-forgotten API functions that nobody's using anymor= e, because we absolutely can, and we absolutely should. However, even more = importantly, that DOES mean we MUST NOT pull the API rug from underneath th= e apps that are still alive and kicking.<br><br><b><font size=3D"4">## CONC= LUSION</font></b><br><br>Here comes libpng version 2: just like libpng vers= ion 1.6, newer, better, more feature-complete, and also, VERY IMPORTANTLY, = with a drama-free upgrade that should be no different from what we had from= libpng 1.0 to 1.2, or from libpng 1.5 to 1.6.<br><br>We should never stop = working on the old libpng codebase, but rather, we should modernize it when= ever the opportunity presents itself, such as, for example, here and now.<b= r><br>For the compiled library names, I propose libpng2.dll (on Windows), l= ibpng.2.dylib and libpng.2.0.dylib (on Mac), libpng.so.2 and libpng.so.2.0 = (elsewhere on Unix). New features added? Upgrade to libpng-2.1. A patchleve= l release to v2.1, with no new features added? Upgrade to libpng-2.1.1. Mor= e patchlevel releases, security fixes, etc? Upgrade to libpng-2.1.2, libpng= -2.1.3, etc. Keep going until the next new PNG feature support comes in lib= png, when it's time to upgrade to libpng-2.2. The compiled library name= remains unchanged, i.e. libpng2.dll and libpng.2.dylib and libpng.so.2.<br= ><br>... until we break ABI compatibility again for some reason, just as we= did it less than a handful of times in more than a quarter-century. That w= ould be the time for us to move up to libpng-3.0 and libpng3.dll, etc. And = so on and so forth, to libpng-4.0 and libpng4.dll etc., etc.<br><br>Let us = not forget to skip far-in-the-future libpng versions entirely, such us libp= ng version 10.0, and also version 12.0, and also version 14.0 and 15.0 and = 16.0. I would suggest transitioning from version 8.x to version 9.0, and th= en, from version 9.x to version 20.0, and then, from version 20.x to versio= n 21.0; but that should be another story for another century.<br><br><b><fo= nt size=3D"4">## NEXT STEPS</font></b><br><br>For the immediate future, we = will continue business-as-usual with our current development branches "= ;libpng16" and "libpng18". I will continue adding changes to= "libpng18" then cherry-pick them into "libpng16" as ap= propriate. Then publish libpng-1.6.45. Then fork off the branch for libpng-= 2.0.<br><br>Suggestions (on any topic) are welcome.<br><br><b><font size=3D= "4">## QUESTIONS?</font></b><br><br>;-)<br><br>Sincerely,<br><div>Cosmin</d= iv><br></div> _______________________________________________<br> png-mng-implement mailing list<br> <a href=3D"mailto:png-mng-implement-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org" rel=3D"noreferre= r noreferrer" target=3D"_blank">png-mng-implement-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org</a>= <br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/png-mng-implement" = rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.so= urceforge.net/lists/listinfo/png-mng-implement</a><br> </blockquote></div></div></div> --000000000000c95caf06227d347a-- --===============4638535834494603451== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============4638535834494603451== 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 --===============4638535834494603451==--