| AWARE [SYSTEMS] | Imaging expertise for the Delphi developer | |||||||
![]() |
TIFF and LibTiff Mailing List Archive | |||||||
LibTiff Mailing List
TIFF and LibTiff Mailing List Archive Contact
The TIFF Mailing List Homepage |
Thread2008.12.18 06:00 "Re: tiffvers.h - TIFFLIB_RELEASE macro addition", by Frank WarmerdamBob 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 |
|||||||