# How to Maintain Consistent Julia Package Versions Across a Team - Julia & ModelingToolkit Versioning Issues – Best Practices?

**URL:** <https://discourse.julialang.org/t/how-to-maintain-consistent-julia-package-versions-across-a-team-julia-modelingtoolkit-versioning-issues-best-practices/127445>\
**Category:** New to Julia\
**Tags:** question, package\
**Created:** [March 28, 2025, 10:17am UTC](https://discourse.julialang.org/t/how-to-maintain-consistent-julia-package-versions-across-a-team-julia-modelingtoolkit-versioning-issues-best-practices/127445 "2025-03-28T10:17:45Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Niyas\_Navas](https://avatars.discourse-cdn.com/v4/letter/n/f04885/32.png) [@Niyas\_Navas](https://discourse.julialang.org/u/Niyas_Navas)\
**Post date:** [March 28, 2025, 10:17am UTC](https://discourse.julialang.org/t/how-to-maintain-consistent-julia-package-versions-across-a-team-julia-modelingtoolkit-versioning-issues-best-practices/127445/1 "2025-03-28T10:17:46Z")

</div>

Hello everyone,

Our team has been working with **Julia and ModelingToolkit.jl** for a project, and after updating to the latest versions, we are facing issues. We are seeking guidance on:

1. **How to enforce specific package versions across our team** to maintain consistency.
2. **How to stay updated on changes in ModelingToolkit** (such as function name changes and deprecated syntax) to avoid future compatibility issues.

## **Background**

We initially installed **Julia 1.10.5** (September 2024) and cloned our repository. We activated the environment and instantiated dependencies with:

```julia-auto
using Pkg
Pkg.activate(".")
Pkg.instantiate()

```

- Our `Project.toml` contained:

```julia-auto
[deps]
DifferentialEquations = "0c46a032-eb83-5123-abaf-570d42b7fbaa"
IJulia = "7073ff75-c697-5162-941a-fcdaad2a7d2a"
ModelingToolkit = "961ee093-0014-501f-94e3-6117800e7a78"
Plots = "91a5bcdd-55d7-5caf-9e0b-520d859cae80"

```

- Our **installed versions** (from `Manifest.toml`) were:  
DifferentialEquations.jl\*\* → `7.12.0`  
IJulia.jl\*\* → `1.24.2`  
ModelingToolkit.jl\*\* → `8.75.0`  
Plots.jl\*\* → `1.40.8`

Everything was working fine with **Julia 1.10.5** and these package versions.

## **The Problem**

Recently, we:

1. **Upgraded to Julia 1.11.4**
2. **Updated all packages** to their latest versions

After doing this, many functions \* After doing this, many functions \ ***stopped working** \* because they no longer exist in the updated packages.

For example, functions like `states(sys)` (which worked in ModelingToolkit 8.75.0) no longer function correctly in the latest version.

## **❓ Questions & Help Needed**

### **1️⃣ How to Enforce Specific Package Versions Across Our Team?**

We want **all team members to use the exact same package versions** , no matter which Julia version they have.

How should we modify `Project.toml` or use `Pkg` commands to enforce this?  
Is there a way to **lock specific versions** across all machines in our team?

* * *

### **2️⃣ How to Stay Updated on ModelingToolkit Function Changes?**

Many functions seem to have changed or been deprecated.  
Is there an **official changelog** or an easy way to track function name changes and syntax updates?

What’s the best way to avoid running into unexpected issues when upgrading?

### **💡 Any insights, best practices, or recommendations would be highly appreciated!**

Thanks in advance for your help. 😊

---

<div class="post-metadata">

**Author:** ![baggepinnen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/baggepinnen/32/693_2.png) [@baggepinnen](https://discourse.julialang.org/u/baggepinnen)\
**Post date:** [March 28, 2025, 10:26am UTC](https://discourse.julialang.org/t/how-to-maintain-consistent-julia-package-versions-across-a-team-julia-modelingtoolkit-versioning-issues-best-practices/127445/2 "2025-03-28T10:26:16Z")

</div>

> [@Niyas\_Navas](#):
>
> Many functions seem to have changed or been deprecated.  
> Is there an **official changelog** or an easy way to track function name changes and syntax updates?

> <https://github.com/SciML/ModelingToolkit.jl/blob/v9.0.0/NEWS.md>

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [March 28, 2025, 10:27am UTC](https://discourse.julialang.org/t/how-to-maintain-consistent-julia-package-versions-across-a-team-julia-modelingtoolkit-versioning-issues-best-practices/127445/3 "2025-03-28T10:27:47Z")

</div>

Note that Semantic Versioning signals that changes to the highest version number are indicators of a breaking change. Major.minor.patch, where updating a major is a signal of breaking changes. See [https://semver.org/](https://semver.org/) for details.

In particular, MTK v9’s release notes mentioning what the breaking changes were is as Fredrik mentioned inhttps://github.com/SciML/ModelingToolkit.jl/blob/master/NEWS.md . In particular at the very top of that is:

> The function `states` is renamed to `unknowns` .

which is one of the largest breaks we have done, and control engineers rejoiced because they really disliked `states`, yadayada, details details, but that should help you upgrade.

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [March 28, 2025, 10:28am UTC](https://discourse.julialang.org/t/how-to-maintain-consistent-julia-package-versions-across-a-team-julia-modelingtoolkit-versioning-issues-best-practices/127445/4 "2025-03-28T10:28:05Z")

</div>

I’m sure you’ll get more detailed and interesting insight from people closer to the MTK ecosystem, but very briefly:

1. How to enforce specific package versions - that’s what the manifest file is for, rather than the project file. However you further specify that you want people to use the exact same package versions no matter which Julia version they are on. This won’t be possible in general, as packages can have different Julia version compatibilities for different package versions (e.g. a package might release a new version and drop compat for an older Julia version). Since Julia 1.11 (?) manifests are version specific though, so you can at least enforce everyone on the same Julia version to have the same package versions.

2. Not sure what kind of release notes MTK uses, but in general you can check GitHub for releases:

> **[Release v9.0.0 · SciML/ModelingToolkit.jl](https://github.com/SciML/ModelingToolkit.jl/releases/tag/v9.0.0)**
>
> ModelingToolkit v9.0.0
> Diff since v8.75.0
> Merged pull requests:
> 
> \[BREAKING Don't merge\] Support DynamicQuantities (#2349) (@YingboMa)
> add component-based hybrid system test (#2355) (@baggepinnen)
> G...

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [March 28, 2025, 10:43am UTC](https://discourse.julialang.org/t/how-to-maintain-consistent-julia-package-versions-across-a-team-julia-modelingtoolkit-versioning-issues-best-practices/127445/5 "2025-03-28T10:43:02Z")

</div>

The endless fight against dependency hell is a lot easier with some restrictions in Project.toml’s [`[compat]` field](https://pkgdocs.julialang.org/v1/compatibility/#Compatibility) though; there’s a team standard that can be incrementally adjusted if updates improve or break anything. Could definitely stop people independently upgrading major versions of dependencies without knowing.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [March 28, 2025, 11:08am UTC](https://discourse.julialang.org/t/how-to-maintain-consistent-julia-package-versions-across-a-team-julia-modelingtoolkit-versioning-issues-best-practices/127445/6 "2025-03-28T11:08:40Z")

</div>

You could use the `freeze(Pkg)` function of the package [GitHub - ufechner7/PkgHelpers.jl: Helper functions for the Julia package manager](https://github.com/ufechner7/PkgHelpers.jl) to freeze your package versions.

But this is not always the best approach.

I usually freeze the version only for packages that have breaking changes very often, for example i currently use

```julia
[compat]
LinearSolve = "=2.39.0"
ModelingToolkit = "~9.54.0"

```

in my `Project.toml` file.

In addition, when I have a working set of packages I create the files:

```julia
Manifest-v1.10.toml.default
Manifest-v1.11.toml.default

```

as copy of the last working Manifest.toml file and add them to git.

You can then have an install script that renames the correct file to Manifest-v1.10.toml or Manifest-v11.toml depending on the Julia version you are using and instantiates the manifest.

See for example: KiteModels.jl

But don’t expect that you can avoid any breakage completely. If you want new features you will always have to test new package versions and update the Project and possibly Manifest files in your repo if you think it makes sense.

---

<div class="post-metadata">

**Author:** ![cstjean](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cstjean/32/1444_2.png) [@cstjean](https://discourse.julialang.org/u/cstjean)\
**Post date:** [March 28, 2025, 12:17pm UTC](https://discourse.julialang.org/t/how-to-maintain-consistent-julia-package-versions-across-a-team-julia-modelingtoolkit-versioning-issues-best-practices/127445/7 "2025-03-28T12:17:17Z")

</div>

> [@Niyas\_Navas](#):
>
> We want **all team members to use the exact same package versions** , no matter which Julia version they have.
> 
> How should we modify `Project.toml` or use `Pkg` commands to enforce this?  
> Is there a way to **lock specific versions** across all machines in our team?

I would have a git repo that contains just a Project.toml and Manifest.toml (i.e. an environment). Then all team members git clone that environment and work in it (with `julia --project=.`) Once in a while, some updates the environment with `]up`, and everybody `git pull` the new environment.

Adding `[compat]` bounds to Project.toml isn’t a bad idea, but I personally try to stay up to date with the latest versions unless there’s a breakage.

Instead of a separate git repo, you can also put it in `YourPackage/dev_env`, and `]dev ..`

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [March 28, 2025, 12:34pm UTC](https://discourse.julialang.org/t/how-to-maintain-consistent-julia-package-versions-across-a-team-julia-modelingtoolkit-versioning-issues-best-practices/127445/8 "2025-03-28T12:34:10Z")

</div>

In 1.12 I would say to have a monorepo with all internal packages and have everything in a common `workspace` ([10. Project.toml and Manifest.toml · Pkg.jl](https://pkgdocs.julialang.org/dev/toml-files/#The-%5Bworkspace%5D-section)) so that there is only one manifest file for all packages.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [March 28, 2025, 1:35pm UTC](https://discourse.julialang.org/t/how-to-maintain-consistent-julia-package-versions-across-a-team-julia-modelingtoolkit-versioning-issues-best-practices/127445/9 "2025-03-28T13:35:24Z")

</div>

> [@cstjean](#):
>
> but I personally try to stay up to date with the latest versions unless there’s a breakage.

Well, in my projects there are always a few packages where the newest versions either don’t work at all, or don’t work with my code. I don’t know which packages you use, but packages like ModellingToolkit.jl and Makie.jl have often breaking changes, every few months. So better restrict the versions of these packages in `Project.toml` to a known, working version.

---

<div class="post-metadata">

**Author:** ![cstjean](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cstjean/32/1444_2.png) [@cstjean](https://discourse.julialang.org/u/cstjean)\
**Post date:** [March 28, 2025, 9:33pm UTC](https://discourse.julialang.org/t/how-to-maintain-consistent-julia-package-versions-across-a-team-julia-modelingtoolkit-versioning-issues-best-practices/127445/10 "2025-03-28T21:33:14Z")

</div>

A monorepo suggestion from @kristoffer.carlsson is a big surprise! Do you have any other (non-julia) reading to recommend? Is there any public Julia github monorepo we can look at for inspiration?