2010.12.14 17:55 "[Tiff] patch to tif_jpeg.c", by Dwight Kelly

2011.01.05 02:19 "Re: [Tiff] libtiff 4.0 stable? [was: Regression in libtiff 4.0 CVS when creating a JPEG RGB contig]", by Bob Friesenhahn

On Tue, 4 Jan 2011, Frank Warmerdam wrote:

  1. Part of the distinction between 3.9 and 4.0 is the ABI. 3.9 is the

In fact, that is the main distinction (from the user's point of view).

  1.  I'm not really sure how to produce releases now. Bob knows more how to get all the right versions of autoconf/automake/libtool/etc so I've been leaving the releases to him. But he has less time now and I am too polite to ask a volunteer to do much. Unless Bob volunteers to produce a beta, and final release, is there someone else who would like to take the bull by the horns? I could do it, but I'm a bit afraid of not being able to do it quite right.

It is not particularly difficult for me to do a libtiff release. The main chore is manually editing the HTML equivalent of the ChangeLog. Preparing the HTML is something that anyone can do.

However, as I mentioned before on the list, the main chore to be undertaken before formally releasing 4.0 is to go through the APIs and API documentation and get them appropriately reconciled. In some case the documentation should be updated, while in other cases, certain changes to the API definitions should be reverted (but without changing the actual current ABI). The goal should be that a programmer can write code to the 4.0 API definition which still trivially compiles and works fine with older libtiff. Likewise, code written properly for the 3.9.X API definition should compile and work with 4.0. If this is not the case, then we will be producing a nightmare for application developers.

There are some regressions in CVS HEAD in that the code rejects some TIFF files which used to read ok. These TIFF files are somewhat defective but read ok in older versions of libtiff. One example I am aware of is the case where a private tag is defined, but has zero size. It used to be that we would warn and move on but now we throw a hard error.

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/