Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-e.b-one.net (mx-e.one.com [91.198.169.52])
	by mail9.b-one.net (Postfix) with ESMTP id E869040011B
	for <info@awaresystems.be>; Thu, 18 Dec 2008 07:00:25 +0100 (CET)
X-Virus-Scanned: by one.com
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=6 tests=[none]
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-e.b-one.net (Postfix) with ESMTP id 1CB96C2DC41
	for <info@awaresystems.be>; Thu, 18 Dec 2008 07:00:25 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id E803D1D4489C3;
	Thu, 18 Dec 2008 06:00:23 +0000 (UTC)
Received: from sasl.smtp.pobox.com (a-sasl-fastnet.sasl.smtp.pobox.com
	[207.106.133.19])
	by lists.maptools.org (Postfix) with ESMTP id 2B4EF1CEDFBEC
	for <tiff@lists.maptools.org>; Thu, 18 Dec 2008 06:00:23 +0000 (UTC)
Received: from localhost.localdomain (unknown [127.0.0.1])
	by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id
	6EB1A88C1B; Thu, 18 Dec 2008 01:00:18 -0500 (EST)
Received: from [192.168.2.4] (unknown [67.47.28.121]) (using TLSv1 with
	cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate
	requested)
	by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id
	1312E88C1A; Thu, 18 Dec 2008 01:00:13 -0500 (EST)
Message-ID: <4949E6EB.2090209@pobox.com>
Date: Thu, 18 Dec 2008 01:00:11 -0500
From: Frank Warmerdam <warmerdam@pobox.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
References: <4949D804.5010103@pobox.com>
	<Pine.SOC.4.64.0812172323350.4741@freddy.simplesystems.org>
In-Reply-To: <Pine.SOC.4.64.0812172323350.4741@freddy.simplesystems.org>
X-Pobox-Relay-ID: 25B9DBF2-CCC9-11DD-8AA3-5720C92D7133-06493634!a-sasl-fastnet.pobox.com
Cc: TIFF mailing list <tiff@lists.maptools.org>
Subject: Re: [Tiff] tiffvers.h - TIFFLIB_RELEASE macro addition
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

Bob Friesenhahn wrote:
> On Wed, 17 Dec 2008, Frank Warmerdam wrote:
>> Does the addition of TIFFLIB_RELEASE seem ok to folks?  Any suggestions
>> or caveats?  Hmm, I just discovered that tiffvers.h is autogenerated
>> by "make release" in the main libtiff makefile.  Does anyone know why
>> such a mechanism is used?  It seems like it might be rather involved to
>> cause it to generate the TIFFLIB_VERSION macro.  I'm inclined to revert
>> this to a manual process described in HOWTO-RELEASE unless someone
>> sees a reason for it to be as complicated as it is now.
> 
> In GraphicsMagick I used the versioning information also passed to 
> libtool.  This is useful information since it indicates the available 
> API/API properties of the library.
> 
> The available values are CURRENT, REVISION, and AGE in order of 
> decreasing significance.  For example, CURRENT might be 4.

Bob,

But this is not normally conveniently available to applications building
against libtiff, right?  It requires some sort of configure magic to
extract the libtool versioning and represent it as macros passed into
the application. It wouldn't do anything for someone on windows for
instance.

> The approach you describe still only works if the major release update 
> always offers additional features over the previous major release.

I do not understand this comment.

If we did a major release update that did not contain additional features,
how would that interfere with what I have suggested?

Lee Howard wrote:
 > Frank Warmerdam wrote:
 >> However, as we split the 3.9 and 4.0 branches a "time stamp" no longer
 >> clearly defines the libtiff version well.
 >
 > It's a non-issue for as far as I can foresee.  As I see it, the "time
 > stamp" problem is only a problem if 3.x releases after 3.9.0 are expected.

I can't guarantee it will happen for libtiff, but within the last 2-3 years
I've become enamored of the "stable branch with bug fix releases" approach.

On my main project, I'm currently releasing a 1.4.5 "end of support" release,
after having released a 1.6.0 release, and am shortly expecting one or two
more point releases in the 1.5.x branch (now at 1.5.3).  So there is at least
some reason to believe libtiff will do some of this, and I forsee a long lived
interested in the 3.9 branch.

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

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
