开发者

How maintain revision/build component in version?

开发者 https://www.devze.com 2023-04-11 17:26 出处:网络
After reading a lot of articles/QAs/FAQs/books I become to think that [MAJOR].[MINOR].[REV] is most useful versioning schema to

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 affected 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 cre开发者_运维问答ated 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?


If you still not use (any) SCM, you are on the wrong path. If you don't use builder, which can be integrated with used SCM - you are on the wrong path again

permanent names of files (without *any version-numbers in it) are most easiest way to maintain sources (you have to modify nothing inside on build)

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号