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

2011.01.04 19:47 "Re: [Tiff] Regression in libtiff 4.0 CVS when creating a JPEG RGB contig", by Lee Howard

I didn't realize that the initial change also made its way to the 3.9 branch. That seems a bit dangerous to me for a stable branch, no?

Someone would need to define for me what "stable" means for me to be able to respond properly. My understanding is that 3.9 is a "maintenance" branch and therefore bug-fixes go there as well as critical security fixes (or whatever one may designate should only be committed to a "stable" branch).

As I see it, users will look for the latest round of bug fixes in the latest release. Until 4.0 releases the 3.9 branch is necessarily still the place where users are going to turn to look for bug fixes. Therefore, until the 4.0 release occurs I can't see how 3.9 could be resigned to receiving only a select subset of bug fixes.

I can certainly understand that at this point where we have a development branch and a maintenance branch that any new feature enhancements should go only into the development branch. But in my mind bug-fixes go in both branches at least until the development branch cuts a versioned release.

If I am wrong in this, then I'll happily ignore 3.9 completely. I can't be expected to know when a bug-fix is deemed critical-enough to merit committal to a branch that only gets some certain kinds of bug fixes.

My broader opinion is that our development team is far too small to warrant more than one code branch and that it's really the distributions that provide a meaningful implementation of "stable". I don't think it's within the developer's capabilities to define what is or isn't "stable".