Recommend version pinning strategy for CMake APT repository

Usage
1

Hello,

I am trying to find a better way to maintain our CI, but have heard the following conflicting advice.

Constraints:
My team is required to version pin our dependencies so builds are (mostly) reproducible, and then we have control over when versions change. A rolling release is not suitable for our production builds.
Recommendations from various CMake talks and Craig Scott’s book:
CMake developers - Use the latest CMake you can get ahold of
CMake minimum version - Specify the minimum version of the features you actually use
CMake CI - Run a build with the latest released CMake version, and another build at the same version as you set in cmake_minimum_required to ensure you haven’t added any features that are not available in the minimum version you declare.

To meet all these requirements, we decided to make use of CMake’s apt repository to install a recent version of CMake (3.25 is what we currently pin), and we update it as we need. That said, the kitware apt repository has broken our CI at least twice, by removing a package that we had pinned.

As I noted below, the minor versions of 3.23 and 3.24 are no longer available at all. Our CI used to pin 3.24 but then one day it spontaneously stopped working when that package was not available.
https://gitlab.kitware.com/cmake/cmake/-/issues/24625#note_1377901

Being able to use new versions of CMake without having to compile from source is really excellent, but there does not seem to be any predictability on which minor versions will be maintained or not in the apt repo, or when versions will be removed.

In order to satisfy the constraints and recommendations, what would you all recommend such that our CI continues to work reliably without surprises?

I’ve considered:

  • We mirror CMake, building debians in our CI and hosting them internally, but this is not ideal because we don’t have infrastructure for debian packages
  • Going back to compiling CMake from source on builds, but this is a significant time cost on each build
  • Kitware can provide EOL dates for each of the versions they host which would allow us to plan around removals
2

We don’t delete builds from the repos unless they’re very old. We’ve never uploaded 3.23 or 3.24 to the Jammy repo. The 3.22 build that you saw at https://gitlab.kitware.com/cmake/cmake/-/issues/24625#note_1374705 is from Ubuntu proper, not from our repo. What version of Ubuntu are using in which 3.24 suddenly became unavailable?

3

We’ve had a ton of flux, it could have been back when we were on focal. We upgraded to Jammy last month. Sorry, I don’t have more exact info or logs; build logs older than a month are purged.

How old is “very old”?

4

A few months ago we had an internal discussion about deleting some packages from 2019, but we ultimately decided against it due to the risk that someone might still be using it. So, we have not deleted any old packages thus far.

5

Got it. When these versions are removed, have you considered any way to inform users of it that the package is deprecated?

6

If we ever do decide to remove old packages, we will likely announce it on our Discourse server. However, we don’t anticipate removing any at this time.

7

Thanks Kyle. We’ll pin 3.25 for the foreseeable future.

8

For the record, the meaning of “old” will vary significantly depending on the users. “old” might mean a lot more than 10 years in some circles, with 2019 being considered a very long way from “old”. I’d recommend avoiding any package removal from public repositories unless you really need to take them down. Inevitably, there will be some automated processes that expect those packages to always be there, even if that is not a good long term strategy for continuity of service.