From: eugene.loh@oracle.com
To: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: [PATCH v2 3/4] Sync up the version numbers
Date: Wed, 25 Jun 2025 02:03:02 -0400 [thread overview]
Message-ID: <20250625060305.15707-2-eugene.loh@oracle.com> (raw)
In-Reply-To: <20250625060305.15707-1-eugene.loh@oracle.com>
From: Eugene Loh <eugene.loh@oracle.com>
DTrace has many version numbers -- e.g., for the release, packaging,
and API.
In reality, the variations in numbering have become nearly meaningless:
- Packaging numbers -- like the Version in the dtrace*spec RPM spec
file and the VERSION in GNUmakefile -- have basically been tracking
the DTrace release since 2.0 anyway.
- Stability attributes for idents are haphazard. Generally, they
are 1.0 (or sometimes other 1.x), and all the BPFs are 2.0. While
this is generally accurate, it is not exactly robust, and idents
are sometimes introduced or modified without careful regard to
the version number. Further, the stability of user D scripts is
likely to depend more on kernel variations -- e.g., the contents of
available_filter_functions -- than on D changes.
- Version number updates are susceptible to mistakes, and so there
have been version mismatches.
Bring the version numbers into sync for 2.0.3. Clean up the descriptions
in dt_version.h.
Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
GNUmakefile | 5 +-
dtrace.spec | 1 +
libdtrace/dt_open.c | 4 ++
libdtrace/dt_version.h | 54 ++++++++++++--------
test/unittest/dtrace-util/tst.APIVersion.r | 2 +-
test/unittest/dtrace-util/tst.APIVersion.r.p | 6 +++
test/unittest/options/tst.version.r | 2 +-
test/unittest/options/tst.version.sh | 4 +-
8 files changed, 52 insertions(+), 26 deletions(-)
create mode 100755 test/unittest/dtrace-util/tst.APIVersion.r.p
diff --git a/GNUmakefile b/GNUmakefile
index d1e18bb1b..00269785b 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -3,7 +3,7 @@
# Build files in subdirectories are included by this file.
#
# Oracle Linux DTrace.
-# Copyright (c) 2011, 2024, Oracle and/or its affiliates. All rights reserved.
+# Copyright (c) 2011, 2025, Oracle and/or its affiliates. All rights reserved.
# Licensed under the Universal Permissive License v 1.0 as shown at
# http://oss.oracle.com/licenses/upl.
@@ -14,7 +14,8 @@
SHELL = /bin/bash
PROJECT := dtrace
-VERSION := 2.0.1
+# When updating version, see comments in dt_version.h.
+VERSION := 2.0.3
# Verify supported hardware.
diff --git a/dtrace.spec b/dtrace.spec
index 6bb792acb..dd44a5b67 100644
--- a/dtrace.spec
+++ b/dtrace.spec
@@ -72,6 +72,7 @@ Requires: libdtrace-ctf >= 1.1.0
BuildRequires: libdtrace-ctf-devel >= 1.1.0
%endif
Summary: DTrace user interface.
+# When updating version, see comments in dt_version.h.
Version: 2.0.3
Release: 1%{?dist}
Source: dtrace-%{version}.tar.bz2
diff --git a/libdtrace/dt_open.c b/libdtrace/dt_open.c
index 7d47cab34..6cb797df6 100644
--- a/libdtrace/dt_open.c
+++ b/libdtrace/dt_open.c
@@ -60,6 +60,10 @@ const dt_version_t _dtrace_versions[] = {
DT_VERS_1_6_3, /* D API 1.6.3 */
DT_VERS_1_6_4, /* D API 1.6.4 */
DT_VERS_2_0, /* D API 2.0 */
+ DT_VERS_2_0_1, /* D API 2.0.1 */
+ DT_VERS_2_0_2, /* D API 2.0.2 */
+ DT_VERS_2_0_3, /* D API 2.0.3 */
+ /* When updating version, see comments in dt_version.h. */
0
};
diff --git a/libdtrace/dt_version.h b/libdtrace/dt_version.h
index 0f47ea70d..5cfcab69a 100644
--- a/libdtrace/dt_version.h
+++ b/libdtrace/dt_version.h
@@ -37,32 +37,28 @@ extern "C" {
*
* These #defines are used in identifier tables to fill in the version fields
* associated with each identifier. The DT_VERS_* macros declare the encoded
- * integer values of all versions used so far. DT_VERS_STRING must be an ASCII
- * string that contains the latest version within it along with any suffixes
- * (e.g. Beta). You must update DT_VERS_STRING when adding a new version,
- * and then add the new version to the _dtrace_versions[] array declared in
- * dt_open.c.
+ * integer values of all versions used so far.
*
- * Refer to the Solaris Dynamic Tracing Guide Versioning chapter for an
- * explanation of these DTrace features and their values.
+ * The major number should be incremented when a fundamental change has been
+ * made that would affect all consumers, and would reflect sweeping changes
+ * to DTrace or the D language.
+ *
+ * The minor number should be incremented when a change is introduced that
+ * could break scripts that had previously worked; for example, adding a
+ * new built-in variable could break a script which was already using that
+ * identifier.
+ *
+ * The micro number should be changed when introducing functionality changes
+ * or major bug fixes that do not affect backward compatibility -- this is
+ * merely to make capabilities easily determined from the version number.
+ *
+ * Minor bugs do not require any modification to the version number.
*
* NOTE: Although the DTrace versioning scheme supports the labeling and
* introduction of incompatible changes (e.g. dropping an interface in a
* major release), the libdtrace code does not currently support this.
* All versions are assumed to strictly inherit from one another. If
* we ever need to provide divergent interfaces, this will need work.
- *
- * The version number should be increased for every customer visible release
- * of Solaris. The major number should be incremented when a fundamental
- * change has been made that would affect all consumers, and would reflect
- * sweeping changes to DTrace or the D language. The minor number should be
- * incremented when a change is introduced that could break scripts that had
- * previously worked; for example, adding a new built-in variable could break
- * a script which was already using that identifier. The micro number should
- * be changed when introducing functionality changes or major bug fixes that
- * do not affect backward compatibility -- this is merely to make capabilities
- * easily determined from the version number. Minor bugs do not require any
- * modification to the version number.
*/
#define DT_VERS_1_0 DT_VERSION_NUMBER(1, 0, 0)
#define DT_VERS_1_1 DT_VERSION_NUMBER(1, 1, 0)
@@ -80,8 +76,26 @@ extern "C" {
#define DT_VERS_1_6_4 DT_VERSION_NUMBER(1, 6, 4)
#define DT_VERS_2_0 DT_VERSION_NUMBER(2, 0, 0)
#define DT_VERS_2_0_1 DT_VERSION_NUMBER(2, 0, 1)
+#define DT_VERS_2_0_2 DT_VERSION_NUMBER(2, 0, 2)
+#define DT_VERS_2_0_3 DT_VERSION_NUMBER(2, 0, 3)
+
+/*
+ * When the version number is updated, the following must be kept in sync:
+ *
+ * libdtrace/dt_version.h DT_VERS_STRING, an ASCII string that contains
+ * the latest version within it along with any
+ * suffixes (e.g. Beta)
+ *
+ * libdtrace/dt_open.c _dtrace_versions[]
+ *
+ * dtrace.spec Version
+ *
+ * libdtrace/Build libdtrace_VERSION
+ *
+ * GNUmakefile VERSION
+ */
-#define DT_VERS_STRING "Oracle D 2.0"
+#define DT_VERS_STRING "Oracle D 2.0.3"
#ifdef __cplusplus
}
diff --git a/test/unittest/dtrace-util/tst.APIVersion.r b/test/unittest/dtrace-util/tst.APIVersion.r
index 6bc7b9d72..02bf03150 100644
--- a/test/unittest/dtrace-util/tst.APIVersion.r
+++ b/test/unittest/dtrace-util/tst.APIVersion.r
@@ -1 +1 @@
-dtrace: Oracle D 2.0
+dtrace: Oracle D 2.0.x
diff --git a/test/unittest/dtrace-util/tst.APIVersion.r.p b/test/unittest/dtrace-util/tst.APIVersion.r.p
new file mode 100755
index 000000000..32ec94df4
--- /dev/null
+++ b/test/unittest/dtrace-util/tst.APIVersion.r.p
@@ -0,0 +1,6 @@
+#!/usr/bin/gawk -f
+
+# The test allows the version string to vary in micro number as well as
+# other suffixes (like "Beta"). The .r.p and .r files still need to be
+# updated for each minor number change.
+{ sub("^dtrace: Oracle D 2\\.0\\..*$", "dtrace: Oracle D 2.0.x"); print }
diff --git a/test/unittest/options/tst.version.r b/test/unittest/options/tst.version.r
index 15010b3db..882e208ed 100644
--- a/test/unittest/options/tst.version.r
+++ b/test/unittest/options/tst.version.r
@@ -1,2 +1,2 @@
-version is 2.0
+version is 2.0.x
diff --git a/test/unittest/options/tst.version.sh b/test/unittest/options/tst.version.sh
index ffffcdd8b..684120af8 100755
--- a/test/unittest/options/tst.version.sh
+++ b/test/unittest/options/tst.version.sh
@@ -1,7 +1,7 @@
#!/bin/bash
#
# Oracle Linux DTrace.
-# Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
+# Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved.
# Licensed under the Universal Permissive License v 1.0 as shown at
# http://oss.oracle.com/licenses/upl.
#
@@ -9,7 +9,7 @@
dtrace=$1
myversion=`$dtrace $dt_flags -V | gawk '{ print $NF }'`
-echo version is $myversion
+echo version is $myversion | sed 's:2.0.[0-9]:2.0.x:'
$dtrace $dt_flags -xversion=$myversion -qn 'BEGIN { exit(0) }'
exit $?
--
2.43.5
next prev parent reply other threads:[~2025-06-25 6:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-25 6:03 [PATCH v2] Optimize USDT discovery a little eugene.loh
2025-06-25 6:03 ` eugene.loh [this message]
2025-07-22 10:51 ` [DTrace-devel] [PATCH v2 3/4] Sync up the version numbers Nick Alcock
2025-06-25 6:03 ` [PATCH v2 4/4] test: Add test for predefined preprocessor definitions eugene.loh
2025-06-25 6:03 ` [PATCH v2 2/2] Extend the USDT bit mask to multiple words eugene.loh
2025-07-22 12:34 ` Nick Alcock
2025-07-23 0:47 ` Eugene Loh
2025-06-25 6:03 ` [PATCH] test: Extend timeout for many-pids test eugene.loh
2025-07-22 12:44 ` Nick Alcock
2025-07-22 10:45 ` [PATCH v2] Optimize USDT discovery a little Nick Alcock
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250625060305.15707-2-eugene.loh@oracle.com \
--to=eugene.loh@oracle.com \
--cc=dtrace-devel@oss.oracle.com \
--cc=dtrace@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox