Comment 4 for bug 903340

(In reply to comment #1)
> Something smells fishy here: since when *forward* compatibility became a
> requirement for tools like intltool ?

Because intltool.m4 is copied into configure scripts, and those configure scripts will be run on systems with a different version of intltool utilities installed.

> I don't really see the point.

Consider the following scenario:

You are the author of a typical gnome package.
In your package's configure.ac, you have IT_PROG_INTLTOOL(0.30).
You upgrade to intltool-0.50.0 on your development machine.
You release a new version of your package and generate a release tarball (./autogen.sh; ./confugure; make; make test; make dist-xz).
Your autogen.sh calls gnome-autogen.sh, which calls intltoolize and autoreconf, and so your package's configure script is re-generated using intltool-0.50's new intltool.m4.
All tests pass, configure output says "checking for intltool >= 0.30... 0.50.0 found", so you assume that everything is fine, and that anyone with >=intltool-0.30 will be able to build your package.
You upload the tarball to ftp.
A user who has intltool-0.41 installed downloads the tarball.
The user runs configure; configure output says "checking for intltool >= 0.30... 0.41.0 found", so the user assumes that everything is fine and he has all dependencies installed.
The user runs make, and the build fails due to a --no-translations argument that his version of intltool-merge does not support.
The user is confused, assumes your package's build system is broken, and writes angry bug reports.

> I'm not saying it's completely unreasonable, but it seems like fixing
> something, that ain't broken - there was a purpose for the change:

Please re-read the patch and intltool.m4. The patch does *not* change intltool's behavior when intltool-0.50's intltool.m4 is used with intltool-0.50's intltool-merge.

Specifically:

If some package's configure script is generated using intltool-0.50's intltool.m4 and that configure script is run on a system with intltool-0.50, then at package build time intltool-merge 0.50 is called with "-x -u --no-translations", and the build succeeds.
With my patch, the behavior is the same.

If some package's configure script is generated using intltool-0.41.1's intltool.m4 and that configure script is run on a system with intltool-0.50, then at package build time intltool-merge 0.50 is called with "-x -u /tmp", and the build succeeds.
With my patch, the behavior is the same.

If some package's configure script is generated using intltool-0.50.0's intltool.m4 and that configure script is run on a system with intltool-0.41.1, then currently, at package build time intltool-merge 0.41.1 is called with "-x -u --no-translations", and the build fails.
With my patch, in this case intltool-merge 0.41.1 is called with "-x -u /tmp" (i.e. the same as it would have been if configure were generated using intltool-0.41.1's intltool.m4), and the build succeeds.