Phil, I'm curious how 0.20 will be released; will it still be a single tarball that contains everything in CVS, or do you anticipate separate release files for e.g. libconcord and concordance, albeit presumably released at the same time from the same snapshot/tag?
Also, some distros (Fedora at least, I'm sure) may have a problem including the content of the "examples" directory from CVS, since those files are essentially binary blobs, and most (c) Logitech. Does it make sense to remove those files from releases for this reason? Also, they're probably only useful for 1 kind of remote anyway. Finally, we probably need to modify the shared-library filename to include some representation of the release number in the filename - e.g. libconcord.so.0.0.20 instead of libconcord.so.0.0.0. This will allow applications to ensure they pick up a compatible library. Actually, simply including the release number in the filename may not be sufficient, since releases may not have compatible ABIs/APIs, and I think the first numeric field is what the dynamic loader uses for compatibility checks. Perhaps the naming should be something more like: libconcord.${abi}.${release} where abi is 0 right now, but increments by 1 each time we make an incompatible API change (or at least once per release that does that). (Or, maybe libtool can be told to make the app/loader run-time link against the fully versioned DSO filename, not just the first numeric component). ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel