This is probably not a smart question. But I am not knowledgable about the inner workings of versions of projects and Julia etc.
I have a DrWatson project on Julia 1.7, and I am now thinking about upgrading to Julia 1.9.
The question is, will I be able to use my project for both versions?
I see that the version of julia is specified in the Project.toml and Manifest.toml.
What should I do in case I want to keep the project for the Julia 1.7 untouched? Should I keep two separate copies of the project?
1 Like
I would recommend making a v1.7-specific Git branch, committing your v1.7 manifest/project state to that branch, then switching back to your main branch and running Pkg.instantiate()
with v1.9 to update the manifest & dependencies.
1 Like
That’s a good and simple idea. Thanks!
The only thing is that it is a bit hard to work in parallel on the two versions.
I was wondering what is the proper way of upgrading the DrWatson project to the new Julia version.
According to what you wrote, I should just instantiate
the project, and all packages would be updated to the new version?
Is that all I need to do?
Sorry, slip of the tongue - instantiate
will install the package versions recorded in the manifest, update
will update to the latest versions.
So update
will rewrite the Manifest.toml
and Project.toml
files to the last version of the packages?
What happens if update
the project in the current Julia version? It does the same? Namely rewrites the Manifest.toml
and Project.toml
files to the last version of the packages?
Yes to both points, with the caveat that update
will not get the latest versions of each package, but rather the latest versions satisfying every dependency’s compatibility requirements. If one of your dependencies doesn’t work with the latest version of another dependency, that’ll be constrained to the latest compatible version.
1 Like
So I guess it is a good idea to update
every once in a while.
Is there a way to check what will be updated before it is actually updated?
Yes, since new releases often contain bug fixes, but if you’re trying to make some simulation or analysis reproducible, you may want to wait until finishing your work before updating, since you don’t want package behavior to potentially change in breaking ways when you’re in the middle of something.
If you do Pkg.status()
(or status
in the Pkg REPL), you’ll see little flags next to each package for which an update is available. It’s possible that not every package will be fully updated due to the compatibility considerations previously mentioned, but that can’t be previewed ahead of the update. If you’re unhappy with the results of an update, you can do Pkg.undo()
to revert to the previous state.
1 Like
Thanks so much! That is very helpful!
1 Like