LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
January 2011
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2011.01.07 14:58 "Re: libtiff 4.0 stable? [was: Regression in libtiff 4.0 CVS when creating a JPEG RGB contig]", by Edward Lam
On 1/4/2011 9:19 PM, Bob Friesenhahn wrote: > 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. This is where I wish we had a wiki for the project. Important information like this is easily lost in a mailing list. Ideally, we have a detailed check list of the tasks needed to move to a 4.0 release so that we can have others help. > 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. Are there particular API areas which you are concerned? Or is this just a general thing where someone needs to diff through the API again between 3.9 and 4.0? FWIW, the only change I encountered when adding support for libtiff 4.0 (back in May 2008) was to change our use of TIFFFindFieldInfo to TIFFFindField. > 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. Do we have a meta bug that tracks these issues which block 4.0 from being released? If not, could you add one? Thanks, -Edward