-
Notifications
You must be signed in to change notification settings - Fork 1
/
release_versioning
92 lines (85 loc) · 3.54 KB
/
release_versioning
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
#==============================================================================
# Release and shared library version control for the common tools interface.
#
# Copyright 2011-2023 Hewlett Packard Enterprise Development LP.
# SPDX-License-Identifier: Linux-OpenIB
#
# Note: After changing this file one must 'autoreconf -ifv' AND 'configure'
# needs to be committed.
#
# LIBTOOLS VERSIONING SYSTEM
# --------------------------
# current, revision, and age are a libtools concept. They are completely
# orthogonal to the Cray release version system (which correlates with
# the module name (e.g. cray-cti/1.0.1))
#
# Libtools flag: -version-info <current>:<revision>:<age>
#
# 'current' combines the roles of major and minor versions so it updated
# every time the API changes.
# 'age' is the number of previous versions that the current version is
# backward compatible with. So normally age == minor version
# 'revision' tracks the *internal* changes of the library, so should be
# updated whenever the binaries change in any way.
#
# The following explanation may help to understand the above rules a
# bit better: consider that there are three possible kinds of reactions
# from users of your library to changes in a shared library:
#
# 1. Programs using the previous version may use the new version as drop-in
# replacement, and programs using the new version can also work with the
# previous one. In other words, no recompiling nor relinking is needed.
# In this case, bump revision only, don’t touch current nor age.
#
# 2. Programs using the previous version may use the new version as drop-in
# replacement, but programs using the new version may use APIs not present
# in the previous one. In other words, a program linking against the new
# version may fail with “unresolved symbols” if linking against the old
# version at runtime: set revision to 0, bump current and age.
#
# 3. Programs may need to be changed, recompiled, and relinked in order to use
# the new version. Bump current, set revision and age to 0.
#
# RELEASE VERSION
# ---------------
# The traditional release version is tracked by the three digit
# common_tool_major.common_tool_minor.common_tool_revision string.
#
# Note that both version are only updated once per release, not every time
# a change is made.
#
# DSO FILE NAMES:
# ---------------
# The file names of the DSO files are ('-' = 'minus' not 'dash'):
# libcommontools_fe.so.fe_current-fe_age.fe_age.revision
# libcommontools_be.so.be_current-be_age.be_age.revision
#
# JENKINS INTEGRATION
# -------------------
# We now key off the BUILD_NUMBER environment variable from jenkins
# to get the revision number. We hardcode the revision to "9999" if the
# environment variable is not set.
#
#----- the rules in summary --------------------------------------------------
# if the new release removes or changes an existing interface:
# increment common_tool_major, be_current and fe_current
# reset common_tool_minor, be_age and fe_age = 0
# else if the new release adds new interface functions:
# increment common_tool_minor, be_current, be_age, fe_current and fe_age
# else:
# leave the versions alone
#
# NOTE: If you bump the major number then reset the minor and revision to 0
# If you bump the minor number then reset the revision to 0
#==============================================================================
common_tool_major="2"
common_tool_minor="18"
revision="5"
# Jenkins will override this
build_number=""
be_current="4"
be_age="2"
be_revision="0"
fe_current="4"
fe_age="2"
fe_revision="0"