Stability of Julia between versions

General Usage
1

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.

2

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?

2 Likes
3

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.

4

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

5

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.

4 Likes
6

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.

5 Likes
7

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.

2 Likes
8

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

9

That sounds correct to me.

1 Like
10

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.)

2 Likes
11

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.”, 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”, 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.

3 Likes
12

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.

3 Likes
13

Bonus: it is possible to pin package versions 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.

3 Likes