5 ms·
With Pkg(3) you can lock library versions (including standard library). As the Julia API won't change in 1.x it won't break after upgrading. You should be fine.
by chappi42 8y ago
With Pkg(3) you can lock library versions (including standard library). As the Julia API won't change in 1.x it won't break after upgrading. You should be fine.
On the other hand, as far as I understand, 1.0 means that the API is stable but not that all 'luxury' features (debugger, Atom/VSC code integration, etc) are perfectly working and/or even ready. This will come in future (it needs a stable API).
- tavert 8y agostdlib modules aren't versioned separately from the language. That may happen in some 1.x release but it's not usable today.
- chappi42 8y agoI took the info from this post: https://discourse.julialang.org/t/feedback-on-inconsistent-naming-of-types-for-julia-v1-0-release/7923/7 https://discourse.julialang.org/t/feedback-on-inconsistent-n.... And e.g. https://github.com/JuliaLang/julia/tree/master/stdlib/LinearAlgebra https://github.com/JuliaLang/julia/tree/master/stdlib/Linear... looks like a proper Pkg(3) package? Sorry for misinformation. Thought this would be for 1.0 already.
- tavert 8y ago"proper package" in that it has a toml file and a uuid, but it can't be controlled by the package manager in terms of updating, handling installation, or pinning versions. The stdlib "packages" are an awkward in-between state that isn't usable the way a full package would be, the only thing it has forced people to do relative to being included in Base is now you need to do `using LinearAlgebra` to load it in downstream code. That might get fixed eventually so you can express that you depend on the LinearAlgebra 1.0 API to isolate yourself from stdlib breakage, but there's no way to do that today short of doing the work yourself to create a full versioned package with the same content.