# Recommend version pinning strategy for CMake APT repository

**URL:** https://discourse.cmake.org/t/recommend-version-pinning-strategy-for-cmake-apt-repository/8363
**Category:** Usage
**Created:** [June 20, 2023, 3:54pm UTC](https://discourse.cmake.org/t/recommend-version-pinning-strategy-for-cmake-apt-repository/8363 "2023-06-20T15:54:16Z")
**Posts on this page:** 8
**Page:** 1

<div class="post-metadata">

### Author: ![Ryanf55](https://discourse.cmake.org/user_avatar/discourse.cmake.org/ryanf55/32/3516_2.png) [@Ryanf55](https://discourse.cmake.org/u/Ryanf55)
#### Post date: [June 20, 2023, 3:54pm UTC](https://discourse.cmake.org/t/recommend-version-pinning-strategy-for-cmake-apt-repository/8363/1 "2023-06-20T15:54:16Z")

</div>

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](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

---

<div class="post-metadata">

### Author: ![kyle.edwards](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/k/65b543/32.png) [@kyle.edwards](https://discourse.cmake.org/u/kyle.edwards)
#### Post date: [June 20, 2023, 3:59pm UTC](https://discourse.cmake.org/t/recommend-version-pinning-strategy-for-cmake-apt-repository/8363/2 "2023-06-20T15:59:50Z")

</div>

> [@Ryanf55](#):
>
> Our CI used to pin 3.24 but then one day it spontaneously stopped working when that package was not available.

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](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?

---

<div class="post-metadata">

### Author: ![Ryanf55](https://discourse.cmake.org/user_avatar/discourse.cmake.org/ryanf55/32/3516_2.png) [@Ryanf55](https://discourse.cmake.org/u/Ryanf55)
#### Post date: [June 20, 2023, 4:20pm UTC](https://discourse.cmake.org/t/recommend-version-pinning-strategy-for-cmake-apt-repository/8363/3 "2023-06-20T16:20:00Z")

</div>

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”?

---

<div class="post-metadata">

### Author: ![kyle.edwards](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/k/65b543/32.png) [@kyle.edwards](https://discourse.cmake.org/u/kyle.edwards)
#### Post date: [June 20, 2023, 5:05pm UTC](https://discourse.cmake.org/t/recommend-version-pinning-strategy-for-cmake-apt-repository/8363/4 "2023-06-20T17:05:36Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![Ryanf55](https://discourse.cmake.org/user_avatar/discourse.cmake.org/ryanf55/32/3516_2.png) [@Ryanf55](https://discourse.cmake.org/u/Ryanf55)
#### Post date: [June 20, 2023, 5:24pm UTC](https://discourse.cmake.org/t/recommend-version-pinning-strategy-for-cmake-apt-repository/8363/5 "2023-06-20T17:24:51Z")

</div>

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

---

<div class="post-metadata">

### Author: ![kyle.edwards](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/k/65b543/32.png) [@kyle.edwards](https://discourse.cmake.org/u/kyle.edwards)
#### Post date: [June 20, 2023, 5:26pm UTC](https://discourse.cmake.org/t/recommend-version-pinning-strategy-for-cmake-apt-repository/8363/6 "2023-06-20T17:26:53Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![Ryanf55](https://discourse.cmake.org/user_avatar/discourse.cmake.org/ryanf55/32/3516_2.png) [@Ryanf55](https://discourse.cmake.org/u/Ryanf55)
#### Post date: [June 20, 2023, 5:33pm UTC](https://discourse.cmake.org/t/recommend-version-pinning-strategy-for-cmake-apt-repository/8363/7 "2023-06-20T17:33:13Z")

</div>

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

---

<div class="post-metadata">

### Author: ![craig.scott](https://discourse.cmake.org/user_avatar/discourse.cmake.org/craig.scott/32/20_2.png) [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [June 21, 2023, 12:00pm UTC](https://discourse.cmake.org/t/recommend-version-pinning-strategy-for-cmake-apt-repository/8363/8 "2023-06-21T12:00:03Z")

</div>

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.