The usual way of sharing your changes with other developers is to commit them back to the version control system. If others are interested in those changes, they have two possible courses of action: either they can wait until the changes appear as a part of an official release and then switch to using that base release, or they can update their local copy of your package and build it themselves. Note that even if other developers have your package checked out when you perform a commit, the copies will not be magically updated. The developers will have to ask for the update explicitly.
In other words, usually the changes to packages are shared either through a common base release or through source code, not by sharing ready-built products. When official releases are built frequently, there is little reason to do anything else. If your project has daily builds of development base releases that take the latest versions of each package, you might as well choose the daily development snapshot as your base release. You will then find out about package incompatibilities the day after the release has been made.
Having said that, if you wish to share a working release with other developers--say, to make sure you did not introduce any package incompatibilities--you can do so. However, it is very unlikely that you will want to share the working release you use yourself. Very likely it is too unstable for others to use, as header files, libraries and executables come and go as you run make. Therefore, you should create another working release that you use solely for sharing purposes. Then copy your sources into it,[1] configure and build it using the release tools' .srt build method, and leave it for others to use. When you have more changes to apply, you update the sources in the shared release and rebuild it.
The developers who wish to share this working release of yours need to carry out three steps. The first is to make sure that they are using the same base release as you did. The second is to get the libraries and binaries from your shared release. The easiest to do this is for them to go in their working release's library (or binary, respectively) directory and create symbolic links to the files in your shared release's respective area.[2] The third and final step is to point the use directives in their PACKAGE files to the packages they wish to share from your area, by using an absolute path in the fourth field of the use directives (see Section 13.2, ``PACKAGE File Syntax'').[3]
What ever the way a package is shared among the developers, one must pay attention to binary compatibility issues.[4] Only code sharing through an official release is safe in this respect. If a developer uses a version of a package different from the one used in the base release, whether it is by checking out the source from the version control system or by sharing somebody elses working release, there may be changes that render the package incompatible with the other packages in the base release. These difference may or may not manifest themselves as compiler or linker errors, as explained in the warning at the end of Section 8.1.1, ``Choosing Base Release And Package Version''.
Examples of binary incompatibilities include but are not limited to adding or removing functions, subroutines or classes, changing the arguments to a function or a subroutine, removing or adding virtual functions to a class, removing, adding or changing class members or base classes, and changes to inlined functions. Depending on the programming language some of these changes may trigger compile- or link-time warnings or errors. However, many of them can go unnoticed from even the strictest development environment. Therefore, if you compile a package that introduced such changes, you ought to recompile the packages that are influenced. A safe bet is to recompile all the packages that use, directly or indirectly, the package in question.
| [1] | The actual task of copying can take place through the version control system, and is most likely the safest and easiest way of doing it. |
| [2] | On Windows NT they will just have to copy the files. |
| [3] | Note that the release will not freeze a release that has absolute paths in any use directive. Such a PACKAGE file should never be committed into the version control system. |
| [4] | When the problems manifest at source level, the compiler will barf and you will just have to go and fix the problems. It is the binary interface changes that are tricky. |