GNU gettext utilities: Distributed Development
From Get docs
Gettext/docs/latest/Distributed-Development
Next: Files under Version Control, Up: Version Control Issues [Contents][Index]
13.6.1 Avoiding version mismatch in distributed development
In a project development with multiple developers, 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 repository.
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 repository. Otherwise the following damages will likely occur:
- Apparent version mismatch between developers. Since some
gettextspecific portions inconfigure.ac,configure.inandMakefile.am,Makefile.infiles depend on thegettextversion, the use of infrastructure files belonging to differentgettextversions 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
gettextthan the other developers, the distribution will be less well tested than if all had been using the samegettextversion. For example, it is possible that a platform specific bug goes undiscovered due to this constellation.