2008.08.29 22:53 "[Tiff] Some security fixes from RHEL", by Even Rouault

2008.09.04 07:22 "Re: [Tiff] Some security fixes from RHEL", by Andrey Kiselev

Lee,

On Wed, Sep 03, 2008 at 02:39:02PM -0700, Lee Howard wrote:

Sure. And as I understood it 3.9 was originally to be the same as 4.0 but only without BigTIFF.

Well, "only BigTIFF" actually resulted in a huge piece of code being rewritten, so 4.0 can not be considered the same as 3.9. Some parts of library was not changed (e.g., codecs), but other changed a lot. For example, the tag handling became more same in 4.0.

When did 3.9 become "stable" and 4.0 become "development"?

 http://www.asmail.be/msg0054867082.html

But I think that the big part of discussion went off-list. The major problem is that we don't have enough resources to maintain two libtiff branches equally, so 3.9 considered to be "stable" now. It should only incorporate important bugfixes, but no new features (unless someone volunteers to support it).

My point, however, is that there needs to be an active path for newly developed code to make it to public release in a regular and frequent way.

Well, it is simple, new features should go in 4.0. Are you still using 3.9 for your daily tasks? ;-)

Library users who are happy with the library code in 3.8 don't need to go to 3.9, do they?

That depends. There was a hell of a thread just a day ago on the security bugs topic, wasn't it?

The busy-work and development belongs on the 4.0 branch as I understand it.

This is not what I have understood at all. For example, JBIG support is in 3.9 where it wasn't in it in 3.8.

That was done before we split out the BigTIFF branch. After that point we just trying to make 3.9 suitable for release.

Does libtiff even have a stable branch?

Now it does.

I understand, really, I do. Isn't the 3.8 to 3.9 indicator clear enough to show that things are changing?

There are new features such as sane OldJPEG support, nice tiffcrop utility and some other goodies, but they should not break the binary compatibility. I did this mistake once and we should avoid it in the future. Also I hope we will maintain soname a bit more accurate in 4.0.

Best regards,

Andrey

--
Andrey V. Kiselev
ICQ# 26871517