After reading a lot of articles/QAs/FAQs/books I become to think
that [MAJOR].[MINOR].[REV] is most useful versioning schema to
describe compatibility between project version (versioning schema
for developer, does not for marketing).

MAJOR changes is backward incompatible and require changing
project name, path to files, GUIDs, etc.

MINOR changes is backward compatible. Mark introduction of new
features.

REV for security/bug fixes. Backward and forward compatible.

At my job many project depend on internal libraries which stored
on release server (FTP). They have different versions, like:

  1.0.0
  1.1.0
  1.1.1

Path to dependent libraries include version component and hard
coded in build scripts for automatic downloading to *lib* dir.

QUESTION: Is it usual practice to include path to libraries to
build script for in house development?

QUESTION: That is best: include version number in library name or
not? Which component to include? For example:

  libfoo-1.so
  libfoo-1.2.jar
  libfoo-2.3.14.dll

If you include only [MAJOR] you can inline libary name in sources
and with version changes you don't need modify any code. As
library have fixed name you always can ask library version at
runtime (by calling appropriate function).

If you include [MAJOR].[MINOR] component every minor changes
require updating all effected projects (calls for LoadLibrary,
CLASSPATH env var). And you can not check version in runtime as
standard mechanism for searching library in runtime usually does
not allow loading by name with wildcard (like "libbar-2.*").

I think that include [REV] was not needed. You only need to
provide this component somehow for bug reports.

QUESTION: I plan to realize such schema: package releases to
path, like:

  /srv/projs/foo/1.2.2

and created symlink to

  /srv/projs/foo/1.2

from previous path. So every dependent project does not need make
any steps to get latest library. Any one use such schema?