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

2011.01.05 00:03 "Re: [Tiff] libtiff 4.0 stable? [was: Regression in libtiff 4.0 CVS when creating a JPEG RGB contig]", by Frank Warmerdam

On 11-01-04 05:10 PM, Edward Lam wrote:

On 1/4/2011 2:47 PM, Lee Howard wrote:

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".

What about a radical idea like just calling libtiff 4.0 "stable" and split for a 4.1 development branch? It's been about 6 months now since Bob released beta 6 and I haven't seen anyone reporting on this mailing list about 4.0 issues until now (for the patch committed last month).

My fear is that we're adding destabilizing commits into libtiff 4.0 and thus make that much harder for us to do a "stable" 4.0 release. If we never treat libtiff 4.0 as "stable", then it will never cease to be moving target. IMHO, we need a "code freeze" for libtiff 4.0 and aim a for a public release say in 6(?) months from now. Are we even doing any real active development on libtiff 4.0? And if we are, shouldn't we be doing in a 4.1 branch?


Just to give a few of my thoughts.

  1. I generally agree that 3.9 should receive bug fixes, though, like Even, I would be hesitant to back port a risky low value bug fix to 3.9.
  2. Part of the distinction between 3.9 and 4.0 is the ABI. 3.9 is the old API/ABI and is supported since that is likely what will be in distributions for a while. Before the 3.9/4.0 split we didn't really actively maintain a separate stable branch and it is quite possible we won't do so in the 4.x series either.
  3. It has been wonderful in recent weeks to see the flurry of activity, I think mostly by Lee. However, the downside is I'm not sure there haven't been new bugs introduced so it is in some ways an odd time to declare 4.0 "stable".
  4. I'd like to see a new 4.0 beta produced and if there are no obvious problems in a couple of weeks proceed to a full release. If we do this we ought to tread quite lightly with risky bug fixes and avoid new features.
  5. 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.

Best regards,

I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent