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

Reply via email to