13.6.1 Avoiding version mismatch in distributed development

In a project development with multiple developers, using CVS, there should be a single developer who occasionally - when there is desire to upgrade to a new gettext version - runs gettextize and performs the changes listed in Adjusting Files, and then commits his changes to the CVS.

It is highly recommended that all developers on a project use the same version of GNU gettext in the package. In other words, if a developer runs gettextize, he should go the whole way, make the necessary remaining changes and commit his changes to the CVS. Otherwise the following damages will likely occur:

• Apparent version mismatch between developers. Since some gettext specific portions in configure.ac, configure.in and Makefile.am, Makefile.in files depend on the gettext version, the use of infrastructure files belonging to different gettext versions can easily lead to build errors.
• Hidden version mismatch. Such version mismatch can also lead to malfunctioning of the package, that may be undiscovered by the developers. The worst case of hidden version mismatch is that internationalization of the package doesn't work at all.
• Release risks. All developers implicitly perform constant testing on a package. This is important in the days and weeks before a release. If the guy who makes the release tar files uses a different version of GNU gettext than the other developers, the distribution will be less well tested than if all had been using the same gettext version. For example, it is possible that a platform specific bug goes undiscovered due to this constellation.