On Thu, Jun 24, 2021 at 10:41 PM Sebastien Marie <sema...@online.fr> wrote:
> On Thu, Jun 24, 2021 at 08:04:37PM -0600, Matt Dowle wrote: > > > > > It is NOT 16 years old. You keep saying that. There is a different > > development > > process involved here which has upsides and downsides and which I don't > > expect > > you will understand. > > > > That's right. I don't understand. > > Could you explain it then, or point me to a document that explains what > > your development process is? > > Putting two and two together, it seems that it is 16 years plus a bunch > of > > cherry picked bug fixes backported over a very many years. If that's what > > you do, whilst I understand that can make some sense to keep patching > say 5 > > year old libraries, at some point it becomes too old and too risky. > > > > I am not sure to understand why our zlib version (which might be > called a maintained fork from 16 years old version) would be more > risky than pushing a newer version just because 'it is newer'. > There are limits here: 'new' and 'old' need to be defined. I agree with you that upgrading to bleeding edge (releases under say 1 year old) regularly may not be a good idea. I think that may be what you have in mind by 'new'. But, in this particular case, the 'newest' version of zlib is 4 years old. And, there have been no bug fixes since that release, too. That's quite different to 'just because it is newer'. A lot of eyes and usage has been on that zlib version 1.2.11 in the last 4 years. The longer you continue a maintained fork, the bigger the time lag between the patches you are taking from later versions and backporting them to 16 years ago. The bigger the time lag the risker it is. Because the bug fixes in later versions of zlib were made and tested (by zlib devs, and people using those later versions) with those fixes in those later versions of zlib, not 1.2.3 from 16 years ago. The act of backporting bug fixes to earlier versions is not risk free. There are a lot of eyes and dependencies using the zlib versions in the form that they have been released. I guess there are not so many eyes and usage of your maintained fork. These reasons are why I said your maintained fork, in this particular case of the baseline being 16 years ago, is riskier. Not because I was naive to assume the latest one is always better. I did not say that all your maintained forks are risker. I'm just saying there's a limit and having a 16-year old baseline for a maintained fork is beyond that limit, and therefore riskier. We are not hostile to make changes, but at least please told us what > should be changed/adjusted and why it is important for your > use-case. And if it doesn't hurt us too, changes will be done: patches > are accepted. > I already replied on that point in this thread to Theo. Best, Matt > Thanks. > -- > Sebastien Marie >
