[DTrace-devel] [PATCH] Refactor the versioning handling system

[Nick Alcock]

On 6 Mar 2025, Kris Van Hees via DTrace-devel outgrape:

> Nick: see question below (mentions your name to find it easily)

I love the idea of this! (but haven't looked at it closely).

> On Fri, Feb 28, 2025 at 03:55:03PM -0500, Eugene Loh via DTrace-devel wrote:
>> Did it use to be the case that when you ran DTrace you would want to know
>> both what version of the tool is this and what version of the API?  But now
>> there is only one version number?  We've been going that way anyhow, but
>> maybe if we're committing to that simpler versioning, we should say so? 
>> (The whole topic confused me, in any case.)
>
> To my knowledge (and based on the code) there has never been a way to print
> any version other than the _dtrace_version which is the API version.  It is
> possible that prior to Linux a packaging version was assigned other than the
> API version, but that seems doubtful because it would essentially be quite
> meaningless and confusing.
>
> Theoretically, it could be envisioned that there be a tool version
> (cmd/dtrace.c), library version (libdtrace), API version (exposed API of
> libdtrace), and D language version.  But since we are not dealing with a
> complex frontend, multiple consumers, etc... I think that a single version
> suffices for now.  And that seems to be what has been done all along.

Well, yes, but we already spit out more version info with dtrace -vV
(git commit ID info). It is possible that we might stuff more in there
too -- but right now they're all going to advance more or less in
lockstep, and printing the one of them that changes with the highest
frequency (as we are) should do.

>> > new version is introduced.
>> > 
>> > For building, the GNUmakefile and dtrace.spec files will also need
>> > to be updated with the new version number.
>> 
>> Maybe this comment about GNUmakefile and dtrace.spec should be in
>> dt_version.h?  Also, what about libdtrace/Build (and libdtrace_VERSION)?
>
> Hm, yes, I can do that (and make it more generic so it refers to all packaging
> config files that distros might need to update).
>
> As far as libdtrace_VERSION is concerned, I think Nick is best positioned to
> answer whether that should follow the DTrace version or whether keeping it at
> 2.0.0 is the most appropriate action,

Only the SONAME (i.e. usually the first digit) really matters. The rest
is up to individual projects.

Some projects bump on every release, but honestly I think it makes more
sense to bump the middle version number when we add libdtrace API
functions (resetting the last to 0) and the last version on every
release. That way, people can tell whether two library versions will be
compatible if you upgrade by looking at the first digit, and if they'll
be compatible if you *downgrade* by looking at the first and second.

This is rare enough that it shouldn't be a burden (OK, OK, I'm sure
we'll forget it every time and it'll end up exactly the same as what
we're doing now, but in a perfect world...)