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 Note: 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.
automatically generated by info2www version 184.108.40.206