# Opt-in \[compat\] tests ok ? augment ver list;

**URL:** <https://discourse.julialang.org/t/opt-in-compat-tests-ok-augment-ver-list/77048>\
**Category:** Internals & Design\
**Tags:** package-management\
**Created:** [February 25, 2022, 8:00am UTC](https://discourse.julialang.org/t/opt-in-compat-tests-ok-augment-ver-list/77048 "2022-02-25T08:00:23Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![JeffreySarnoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeffreysarnoff/32/1980_2.png) [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)\
**Post date:** [February 25, 2022, 8:00am UTC](https://discourse.julialang.org/t/opt-in-compat-tests-ok-augment-ver-list/77048/1 "2022-02-25T08:00:23Z")

</div>

The introduction of a new version for a [compat] listed package results in nonempty `status --outdated` often enough that a safe opt-in way of reducing these events is desirable.

To ensure the processing happen only if the package owner[s] want it (to prevent the processing otherwise) consider an `.github/workflow/autocompat.toml` that at its most simple would “know” when a [compat] listed package has merged a new version which is not covered by the current `Project.toml`.

In that case, a temporary branch is created and the only changes are to the `Project.toml` (a) bumping the owned package’s version patch number (b) extending that package’s [compat] string to include the new version number (in an intelligent way, to prevent accumulating too many too specific versions)

Then run the owned pkg’s tests on this branch using the new version of the [compat] package. If the tests pass, then merging the change into the main branch with an appropriate comment and register the update.

Within the `.toml` file, finer control would be available. For example, selecting which external pkgs are “active” in this way (if not all [compat] entries) or providing a waiting time before a new version of some/all [compat] pkgs are processed.

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [February 25, 2022, 11:02am UTC](https://discourse.julialang.org/t/opt-in-compat-tests-ok-augment-ver-list/77048/2 "2022-02-25T11:02:30Z")

</div>

This doesn’t sound entirely different from [CompatHelper](https://github.com/JuliaRegistries/CompatHelper.jl), except for the automatic merge parts.

---

<div class="post-metadata">

**Author:** ![JeffreySarnoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeffreysarnoff/32/1980_2.png) [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)\
**Post date:** [February 25, 2022, 11:10am UTC](https://discourse.julialang.org/t/opt-in-compat-tests-ok-augment-ver-list/77048/3 "2022-02-25T11:10:58Z")

</div>

I thought it best to work with what works now with other activity that git supports, and presume a clear+clean way for the rest.  
_I have no experience with github action development_

---

<div class="post-metadata">

**Author:** ![JeffreySarnoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeffreysarnoff/32/1980_2.png) [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)\
**Post date:** [February 25, 2022, 2:04pm UTC](https://discourse.julialang.org/t/opt-in-compat-tests-ok-augment-ver-list/77048/4 "2022-02-25T14:04:24Z")

</div>

Is this reasonably easy to implement?  
Would it be worth the CI overhead $?

---

<div class="post-metadata">

**Author:** ![tbeason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tbeason/32/15898_2.png) [@tbeason](https://discourse.julialang.org/u/tbeason)\
**Post date:** [February 25, 2022, 2:18pm UTC](https://discourse.julialang.org/t/opt-in-compat-tests-ok-augment-ver-list/77048/5 "2022-02-25T14:18:58Z")

</div>

From just a package developer point of view, I agree that the only thing that sounds effectively different from existing CompatHelper workflow is the automatic merge, which seems somewhat risky. CompatHelper opens a PR on a new branch with the right commit and tests will run as long as your CI is set to run on PRs. So the only step of the process that you are eliminating is the button click at the end. To have a fully automatic workflow, you’d need to automatically call Registrator as well for a new release.

---

<div class="post-metadata">

**Author:** ![JeffreySarnoff](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jeffreysarnoff/32/1980_2.png) [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)\
**Post date:** [February 25, 2022, 2:51pm UTC](https://discourse.julialang.org/t/opt-in-compat-tests-ok-augment-ver-list/77048/6 "2022-02-25T14:51:46Z")

</div>

🆗

> _“Never Mind”_ - [Emily Litella](https://en.wikipedia.org/wiki/Emily_Litella)