New Versioning Scheme

[brycelelbach]

I would like to get community feedback on the following proposed new versioning scheme for Thrust.

From #888:

The current list of CUDA-released but not GitHub-released versions of thrust in the last years are:

• CUDA 8.0: 1.8.3-patch2
• CUDA 9.0: 1.9.0-patch5
• CUDA 9.1: 1.9.1-patch2

It sure is confusing to figure out what version of Thrust shipped with a particular release of CUDA. I plan to fix that in the next release of Thrust in CUDA by switching to a new versioning scheme.

In the new scheme, the Thrust major and minor version will be the same as the CUDA major and minor version that is released with [0].

So for example, Thrust v15.0.0 would be released with CUDA 15.0. After the release, the Thrust version number would be bumped to 15.0.1 on the public development branch (which will live on both GitHub and internally at NVIDIA).

Suppose we did a GitHub release in between CUDA releases. It would be called 15.0.1 and the development branch would be bumped to 15.0.2 (we can go up to 15.0.99 if needed).

Let's also suppose that there was a second public release of CUDA 15.0 that contained updates to Thrust. This would be an extraordinary circumstance and I don't think it would ever happen in the future. If it did, we would bump the Thrust patch number - e.g. the second release of CUDA 15.0 would contain Thrust v15.0.0-1. Otherwise, the Thrust patch number will be 0 - as such, going forward we will omit stating the patch number if it is 0 (Thrust v15.0.0 == Thrust v15.0.0-0).

There would also be an internal private development branch - Thrust v15.1.0 - for the next CUDA release, 15.1. 15.1.0 (private dev) and 15.0.2 (public dev) would be almost identical. Everything from 15.0.2 will be in 15.1.0. The only things in 15.1.0 that are NOT in 15.0.2 would be code that depends on the unreleased CUDA 15.1, and thus can't be used by non-NVIDIA people yet.

This new scheme amounts to a version jump from the current 1.y.z series. The existing Thrust version format (XXXXYYYZZ, X = major, Y = minor Z = subminor) would remain the same, the existing Thrust version macros would remain the same, and code that uses those macros would continue to work.

You may be wondering about compatibility with older CUDA versions. See #916 for my proposed compatibility strategy.

[0] CUDA releases do technically have a third release number - the build number. For example, the public release of CUDA 9.2 is CUDA 9.2.88. We will not embed the build number into the Thrust versioning scheme because (a) most CUDA releases and users will only use a single build number and (b) the build number is generated during packaging so there is no easy way for us to include it in the Thrust version header.

TL;DR

Going forward, Thrust vX.Y.Z is the version released with CUDA X.Y.

Thoughts and feedback are most welcome.

[brycelelbach]

Ouch. This is not doable because CMake's FindThrust.cmake assumes Thrust's major version is a single digit. Unfortunately this will probably preclude this from happening anytime soon. However, we can provide another version macro that specifies which version of CUDA a particular version of Thrust was released with.

[ax3l]

The FindThrust.cmake file you are linking is not an official CMake find-module but only part of VTK(-m). This can be fixed in VTK & VTK-m itself, e.g. by replacing the regex from "^[0-9]" to "^[0-9]+" :-) or directly querying the sub-strings that are defined

[ax3l]

@brycelelbach what is the planned format defined in THRUST_VERSION? Does it stay the same?
Are THRUST_MAJOR_VERSION (MINOR/SUBMINOR) guaranteed to stay defined as well? Should we document the patch level in there as well?

[henryiii]

And, if Thrust provided a ThrustConfig.cmake, find scripts would not be needed.

[ax3l]

@brycelelbach regarading CUDA 10 just being released: let's just take your proposed version scheme and add a ThrustConfig.cmake to thrust itself as suggested when it's been installed. By that, you have full control over the version string :)

[claudiofantacci]

I also agree that it would be better to provide a ThrustConfig.cmake and a ThrustTarget.cmake to start moving to modern CMake.