libpng version 2.0, anyone?
Cosmin Truta <[email protected]> Thu, 19 Sep 2024 21:05:40 +0300
| Newsgroups | gmane.comp.graphics.png.devel |
|---|---|
| Message-ID | <CAAoVtZwXv1e1T2jO-v3omG7_-o-Tz4BLU_7Ktz9D+mTFXuS_PQ@mail.gmail.com> |
--===============1135241028231928752==
Content-Type: multipart/alternative; boundary="000000000000df614906227cc53b"
--000000000000df614906227cc53b
Content-Type: text/plain; charset="UTF-8"
*## 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.
* 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 when
we break the API compatibility with libpng 1.x.") But: here comes bragging:
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 the
other hand, the cost of maintaining the drama-free-ness in the present-day
libpng v1.6.x for the benefit of its users 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 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 were
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. If
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, for
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 feature
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 did
it less than a handful of times in more than a quarter-century. That would
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, such
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 century.
*## 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
--000000000000df614906227cc53b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<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 &qu=
ot;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 for libpng-2.0.<br>=
=C2=A0* Discard implementation quirks and cruft where possible.<br>=C2=A0* =
Implement all PNG features that are currently missing.<br>=C2=A0* Embrace n=
ew C standard features where feasible.<br>=C2=A0* Adopt Semantic Versioning=
(i.e., "SemVer").<br>=C2=A0* Publish a new repository named &quo=
t;pngfuzz".<br><br>What NOT TO DO:<br>=C2=A0* Modernize the libpng API=
.<br>=C2=A0* Gratuitously break compatibility with compilers in use.<br>=C2=
=A0* Gratuitously break the world of PNG-supporting apps.<br><br><font size=
=3D"4"><b>## INTRODUCTION</b></font><br><br>Hello, everyone,<br><br>Among t=
he many traditions that our little group has been having, one of those is t=
o fork version branches and then abandon them. So far we've had "l=
ibpng13" and "libpng17". Coming up next, a branch that I hav=
en't even formally announced yet and I already want to close.<br><br>Th=
e 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 when =
we break the API compatibility with libpng 1.x.") But: here comes brag=
ging:<br><br>I've seen on various forums, every now and then, people sa=
ying VERY good things about how stable libpng is, and how reliable and dram=
a-free its upgrades are, so yeah, go ahead, do upgrade. (Rest In Peace, Gle=
nn.) On the other hand, the cost of maintaining the drama-free-ness in the =
present-day libpng v1.6.x for the benefit of its users has become increasin=
gly high for us developers. In order not to break ABI compatibility and bui=
ld workflows and stuff, we kept on walking on a minefield. Yes, we did a go=
od job, but... the time to retire libpng 1.6.x, and continue 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/li=
bpng/tree/libpng18">https://github.com/pnggroup/libpng/tree/libpng18</a><br=
><br>John Bowler and other contributors have already submitted pull request=
s (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:<br><br><b>**What happens to the public DLL =
and SO library names?**</b><br><br>Naturally, libpng16.dll will be followed=
by libpng18.dll and libpng18.a and libpng18.so.18, and so on.<br>Then come=
s libpng19, then libpng110 (not libpng20), then... ... ...<br><br>And yet..=
. shouldn'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 pa=
st libpng-1.x?**</b><br></div><div><br></div>Here's my advice: anyone w=
ho wants to build a brand and grand and new library from scratch should fir=
st and 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 Jo=
el 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&qu=
ot;, 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,ser=
if">"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."</span></i></span><br><br>So:<br><br>Just as PNG its=
elf is designed to be extensible without breaking compatibility, libpng sho=
uld, also, be extensible without breaking compatibility. That doesn't m=
ean we cannot delete long-forgotten API functions that nobody's using a=
nymore, because we absolutely can, and we absolutely should. However, even =
more importantly, that DOES mean we MUST NOT pull the API rug from undernea=
th the apps that are still alive and kicking.<br><br><b><font size=3D"4">##=
CONCLUSION</font></b><br><br>Here comes libpng version 2: just like libpng=
version 1.6, newer, better, more feature-complete, and also, VERY IMPORTAN=
TLY, 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=
whenever the opportunity presents itself, such as, for example, here and n=
ow.<br><br>For the compiled library names, I propose libpng2.dll (on Window=
s), 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 patc=
hlevel 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, l=
ibpng-2.1.3, etc. Keep going until the next new PNG feature support comes i=
n 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.<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. T=
hat would 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>Le=
t us not forget to skip far-in-the-future libpng versions entirely, such 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, a=
nd then, from version 9.x to version 20.0, and then, from version 20.x to v=
ersion 21.0; but that should be another story for another century.<br><br><=
b><font 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 chang=
es to "libpng18" then cherry-pick them into "libpng16" =
as appropriate. Then publish libpng-1.6.45. Then fork off the branch for li=
bpng-2.0.<br><br>Suggestions (on any topic) are welcome.<br><br><b><font si=
ze=3D"4">## QUESTIONS?</font></b><br><br>;-)<br><br>Sincerely,<br><div>Cosm=
in</div><br></div>
--000000000000df614906227cc53b--
--===============1135241028231928752==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============1135241028231928752==
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
--===============1135241028231928752==--