Gettext/Distributed-Development
From Get docs
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
gettext
specific portions inconfigure.ac
,configure.in
andMakefile.am
,Makefile.in
files depend on thegettext
version, the use of infrastructure files belonging to differentgettext
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 samegettext
version. For example, it is possible that a platform specific bug goes undiscovered due to this constellation.