2014.11.19 23:40 "Re: [Tiff] libtiff release pending?", by Even Rouault

Le jeudi 20 novembre 2014 00:34:20, Bob Friesenhahn a écrit:

I'm OK to give it a try.

In other projects I'm familiar with, to avoid the issue you mention, we bump the shared library versioning numbers when the first beta or RC is cut and don't change them if other beta/RC are done.

And for an RC, we label it internally as if it was the final (for example libtiff/tiffvers.h content), so that only the name of .tar.gz has to be renamed once it is vetted to be OK for final. Does that sound OK? (Otherwise you have to rebuild a new archive, which might introduce new errors)

The shared library minor revision should always change whenever a new tarball is released.

ok, so libtiff-4.0.4RC1.tar.gz and libtiff-4.0.4.tar.gz wouldn't be binary identical?

Otherwise the library from the new package would overwrite the built library from the previous package.

Which would be fine for 4.0.4RC2 with respect to 4.0.4RC1, wouldn't it?

This is part of the libtiff release procedure.

I agree it is needed for the x.y.z number, but perhaps not for each beta/RC iterations?

It seems ok for the versioning used by applications to be updated to the expected final versions.

Not sure to understand what you mean here. Examples?

We use 'make distcheck' to make sure that the library archive is ok. This builds the package in several different ways, running the embedded test suite each time.

--
Spatialys - Geospatial professional services
http://www.spatialys.com