# Stability of Julia between versions
**URL:** https://discourse.julialang.org/t/stability-of-julia-between-versions/100001
**Category:** General Usage
**Created:** [June 7, 2023, 12:44pm UTC](https://discourse.julialang.org/t/stability-of-julia-between-versions/100001 "2023-06-07T12:44:13Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@JuliaBoomer](https://discourse.julialang.org/u/JuliaBoomer)
#### Post date: [June 7, 2023, 12:44pm UTC](https://discourse.julialang.org/t/stability-of-julia-between-versions/100001/1 "2023-06-07T12:44:14Z")
Hello,
I am working on an optimization tool coded in Julia in its version 1.3.1. Until a few months ago, I regularly encountered stability issues, with the tool apparently becoming obsolete after some updates. I would like to know if this issue of incompatibility between versions was acknowledged, and if there are existing solutions to perpetuate the tool, even though it is not coded in the newest version of the language.
---
### Author:  [@cormullion](https://discourse.julialang.org/u/cormullion)
#### Post date: [June 7, 2023, 12:55pm UTC](https://discourse.julialang.org/t/stability-of-julia-between-versions/100001/2 "2023-06-07T12:55:48Z")
Hi there! A bit more detail is probably required to get thorough answers.
Are you talking about the language itself or about one or more packages?
---
### Author:  [@JuliaBoomer](https://discourse.julialang.org/u/JuliaBoomer)
#### Post date: [June 7, 2023, 1:01pm UTC](https://discourse.julialang.org/t/stability-of-julia-between-versions/100001/3 "2023-06-07T13:01:41Z")
Thank you for your fast answer !
The packages I’m using (DataFrames, JuMP, Cbc, GLPK, Logging) are indeed probably involved.
While everything was working the day before, the code sometimes no longer compiles the next day because one function or another can no longer be used in the same way.
---
### Author:  [@JuliaBoomer](https://discourse.julialang.org/u/JuliaBoomer)
#### Post date: [June 7, 2023, 1:04pm UTC](https://discourse.julialang.org/t/stability-of-julia-between-versions/100001/4 "2023-06-07T13:04:41Z")
I was also wondering why debugging does’nt work on VSCode, using Julia 1.3.1 anyway. This doesn’t make it easier to put things together
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [June 7, 2023, 1:10pm UTC](https://discourse.julialang.org/t/stability-of-julia-between-versions/100001/5 "2023-06-07T13:10:15Z")
Welcome! It’s really unclear what you’re doing and what’s happening. Are you trying to run the code in newer versions? Or are you using Julia 1.3.1? Are you updating packages? Or is everything truly staying the same and the code is unstable?
If you could narrow down some more precise descriptions, I imagine there’d be some folks who may be able to help, but that might entail upgrading to run in a newer version of Julia. And while Julia strives to be forwards compatible for upgrades to new versions like this, there can be snags — especially when jumping _so_ far forward across both package and Julia versions.
---
### Author:  [@albheim](https://discourse.julialang.org/u/albheim)
#### Post date: [June 7, 2023, 1:11pm UTC](https://discourse.julialang.org/t/stability-of-julia-between-versions/100001/6 "2023-06-07T13:11:26Z")
If you update packages they might very well change their API, especially if you update over major versions.
If you create an environment and keep the `Manifest.toml` it will keep track of exactly which versions you previously used, and should then allow you to easily reproduce the exact same setup.
---
### Author:  [@aplavin](https://discourse.julialang.org/u/aplavin)
#### Post date: [June 7, 2023, 1:20pm UTC](https://discourse.julialang.org/t/stability-of-julia-between-versions/100001/7 "2023-06-07T13:20:52Z")
> [@albheim](#):
>
> If you create an environment and keep the `Manifest.toml` it will keep track of exactly which versions you previously used, and should then allow you to easily reproduce the exact same setup.
I’d add that keeping the package versions the same is only feasible/allowed when keeping the same julia version. Updating Julia while keeping package versions often does break code.
---
### Author:  [@JuliaBoomer](https://discourse.julialang.org/u/JuliaBoomer)
#### Post date: [June 14, 2023, 1:27pm UTC](https://discourse.julialang.org/t/stability-of-julia-between-versions/100001/8 "2023-06-14T13:27:06Z")
Hello everyone,
Thank you all for your numerous answers and sorry for being so unclear.
Let me try to clarify things. This is the exact environment in which the tool is developed :
```
Status `C:\Users\[...]\.julia\environments\v1.3\Project.toml`
```
[c52e3926] Atom v0.12.30
[a076750e] CPLEX v0.7.6
[336ed68f] CSV v0.8.0
[9961bab8] Cbc v0.7.1
[a93c6f00] DataFrames v0.22.0
[60bf3e95] GLPK v0.14.2
[4076af6c] JuMP v0.20.1
[e5e0dc1b] Juno v0.8.4
[91a5bcdd] Plots v1.6.12
I don’t intend to run the code in any newer version, neither to update packages. All things staying the same, I had encountered a couple of stability problems, back when I was coding on the IDE Atom, as if some packages were updating by their own, thus becoming uncompatible with the existing code. I must admit these problems seem to have resolved themselves since switching to VSCode. However, I wanted to make sure that, if I don’t seek to update anything, nothing will change in my working environment.
Thank you again
---
### Author:  [@albheim](https://discourse.julialang.org/u/albheim)
#### Post date: [June 14, 2023, 8:15pm UTC](https://discourse.julialang.org/t/stability-of-julia-between-versions/100001/9 "2023-06-14T20:15:45Z")
> [@JuliaBoomer](#):
>
> However, I wanted to make sure that, if I don’t seek to update anything, nothing will change in my working environment.
That sounds correct to me.
---
### Author:  [@odow](https://discourse.julialang.org/u/odow)
#### Post date: [June 14, 2023, 8:55pm UTC](https://discourse.julialang.org/t/stability-of-julia-between-versions/100001/10 "2023-06-14T20:55:42Z")
> [@JuliaBoomer](#):
>
> [4076af6c] JuMP v0.20.1
You’re using an old version of JuMP, so if you’re looking at the current documentation it likely won’t work.
You should update to Julia v1.6 and JuMP 1.0. We now have a strong backward compatibility guarantee, so any code you write using JuMP v1.X will work in all future versions.
> However, I wanted to make sure that, if I don’t seek to update anything, nothing will change in my working environment.
But yes, if you don’t change packages, nothing should break.
(You should also note that recent versions of CPLEX, like 22.1 will not work with CPLEX.jl v0.7.6.)
---
### Author:  [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)
#### Post date: [June 14, 2023, 8:56pm UTC](https://discourse.julialang.org/t/stability-of-julia-between-versions/100001/11 "2023-06-14T20:56:08Z")
But it isn’t is it? If you add a new package that has an already installed package in its dependencies it can lead to the already installed package to be updated. I think you need to have a `Project.toml` file and pin all (important) package versions to the exact version used to guarantee that this will not happen by mistake.
`Pkg.add` documentation string is very clear about it:
> help?\> Pkg.add
> Pkg.add(pkg::Union{String, Vector{String}}; preserve=PRESERVE\_TIERED)
> Pkg.add(pkg::Union{PackageSpec, Vector{PackageSpec}}; preserve=PRESERVE\_TIERED)
> Add a package to the current project. This package will be available by using the
> import and using keywords in the Julia REPL, and if the current project is a
> package, also inside that package.
>
> Resolution Tiers
> ==================
>
> Pkg resolves the set of packages in your environment using a tiered algorithm. The
> preserve keyword argument allows you to key into a specific tier in the resolve
> algorithm. The following table describes the argument values for preserve (in
> order of strictness):
>
> Value Description
> ––––––––––––––– –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
> PRESERVE\_ALL Preserve the state of all existing dependencies (including recursive dependencies)
> PRESERVE\_DIRECT Preserve the state of all existing direct dependencies
> PRESERVE\_SEMVER Preserve semver-compatible versions of direct dependencies
> PRESERVE\_NONE Do not attempt to preserve any version information
> PRESERVE\_TIERED Use the tier which will preserve the most version information (this is the default)
>
> Examples
> ≡≡≡≡≡≡≡≡≡≡
>
> Pkg.add(“Example”) # Add a package from registry
> Pkg.add(“Example”; preserve=Pkg.PRESERVE\_ALL) # Add the `Example` package and preserve existing dependencies
> Pkg.add(name=“Example”, version=“0.3”) # Specify version; latest release in the 0.3 series
> Pkg.add(name=“Example”, version=“0.3.1”) # Specify version; exact release
> Pkg.add(url=“[GitHub - JuliaLang/Example.jl: Example Julia package repo.](https://github.com/JuliaLang/Example.jl)”, rev=“master”) # From url to remote gitrepo
> Pkg.add(url=“/remote/mycompany/juliapackages/OurPackage”) # From path to local gitrepo
> Pkg.add(url=“[https://github.com/Company/MonoRepo](https://github.com/Company/MonoRepo)”, subdir=“juliapkgs/Package.jl)”) # With subdir
>
> After the installation of new packages the project will be precompiled. See more
> at Project Precompilation.
>
> See also PackageSpec, Pkg.develop.
---
### Author:  [@albheim](https://discourse.julialang.org/u/albheim)
#### Post date: [June 14, 2023, 9:41pm UTC](https://discourse.julialang.org/t/stability-of-julia-between-versions/100001/12 "2023-06-14T21:41:36Z")
Yeah, I might have misinterpreted OPs question. I took it to mean they weren’t going to change anything in the evironment, but they only stated update.
The answer I was intending to give was more that _if you don’t actively change the environment it should stay the same._
---
### Author:  [@heliosdrm](https://discourse.julialang.org/u/heliosdrm)
#### Post date: [June 14, 2023, 10:04pm UTC](https://discourse.julialang.org/t/stability-of-julia-between-versions/100001/13 "2023-06-14T22:04:53Z")
Bonus: it is possible to [pin package versions](https://pkgdocs.julialang.org/v1/managing-packages/#Pinning-a-package) to ensue that they don’t change their version, even if other operations are done like adding yet another package.
But this only works for the explicitly pinned packages. Indirect dependencies might change anyway, so the safest option is doing nothing at all that might change the Manifest.toml of the environment.