# Too many Julia versions?
**URL:** https://discourse.julialang.org/t/too-many-julia-versions/84538
**Category:** General Usage
**Created:** [July 20, 2022, 2:07pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538 "2022-07-20T14:07:23Z")
**Posts on this page:** 18
**Page:** 1
### Author:  [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [July 20, 2022, 2:07pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/1 "2022-07-20T14:07:23Z")
We often hear in this forum that the man power working on Julia is limited. Why then do we have 1.6, 1.7, 1.8, and 1.9 being worked on at the same time? Too many balls in the air…?
---
### Author:  [@nilshg](https://discourse.julialang.org/u/nilshg)
#### Post date: [July 20, 2022, 2:10pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/2 "2022-07-20T14:10:42Z")
1.6 is the LTS version. 1.7 is the current stable release, which is not actively developed any longer as the release of 1.8 (the next stable release version) is imminent. 1.9 is not really a separate version as such, it’s just the current name of the main development branch after 1.8 has been forked for release.
So in general there will always be work on three versions: LTS, current stable, and dev/nightly. It’s just that at the minute we are transitioning from one stable to another, which is why 1.7 and 1.8 sort of exist in parallel.
---
### Author:  [@Amval](https://discourse.julialang.org/u/Amval)
#### Post date: [July 20, 2022, 2:12pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/3 "2022-07-20T14:12:00Z")
To me this looks pretty normal, with work continuing on 1.9 as the natural consequence of doing feature freeze before an imminent release and backporting bugfixes to a LTS (1.6).
---
### Author:  [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [July 20, 2022, 2:25pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/4 "2022-07-20T14:25:32Z")
OK, that makes sense. I thought 1.7 was still being developed (1.7.3 just appeared, I believe?).
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [July 20, 2022, 2:26pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/5 "2022-07-20T14:26:10Z")
Until 1.8 gets released, 1.7 will get bugfixes.
---
### Author:  [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [July 20, 2022, 2:45pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/6 "2022-07-20T14:45:02Z")
The reason I am a bit concerned is also that package developers are a somewhat taxed with keeping their packages working with so many versions. If I were to test the LTS, 1.7.3, 1.8 latest release candidate, and the nightly, that’s already four versions to switch between every time I want to make a release.
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [July 20, 2022, 2:50pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/7 "2022-07-20T14:50:21Z")
We don’t have enough Julias, I want one more 2.0…, sooner rather than later 🙂
We have basically one more Julia (that is 1.6 LTS) than strictly necessary, and if you develop packages (and i know you do), AND you want to support that one (then you loose out on some new syntax), you should test on it.
You want to test one at least one more recent version, the stable versions, and that’s currently 1.7.
Since 1.8 is close to release, already rc3, it’s recommended to test that one, but you can skip testing on 1.9/nightly for now. When is it likely to be released?
I would want to fork Julia to make Julia 2.0, to try out some of the planned breaking changes from that milestone. It would be completely optional to test on that one, but very helpful to know your code is future-proof.
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [July 20, 2022, 2:59pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/8 "2022-07-20T14:59:46Z")
> [@PetrKryslUCSD](#):
>
> 1.7.3 just appeared, I believe?
Well it’s actually from “May 6, 2022”, so “long” time ago (and I see no 1.7.x planned). I think you have just released 1.6.7 in mind. Actually 1.6.8 and 1.8-rc4 are also coming.
---
### Author:  [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [July 20, 2022, 3:01pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/9 "2022-07-20T15:01:09Z")
Oops, you’re right. It was 1.6.7.
---
### Author:  [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [July 20, 2022, 3:20pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/10 "2022-07-20T15:20:31Z")
IMO, this isn’t that big of a deal. The multiple version testing is pretty well automated by CI. If you don’t have CI set up, set it up. It makes your life a million times better.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [July 20, 2022, 4:49pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/11 "2022-07-20T16:49:13Z")
In principle a package that works on 1.6.x should work on newer 1.X versions.
If you plan to support the LTS release, you can develop and test on it on a daily basis, and let CI tests only for other versions (particularly the current stable release), but they should work.
Currently I don’t find any compelling reason to _not_ support 1.6, so that is what I do most of the time.
---
### Author:  [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [July 20, 2022, 9:12pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/12 "2022-07-20T21:12:08Z")
I do have CI set up. However, I also want to test for performance regressions. Those tests are expensive, and I don’t want to run them as part of the CI.
For some of my packages, I made the step towards 1.7, and there are now two versions of the packages, none of which passes tests with the other julia.
---
### Author:  [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [July 20, 2022, 11:42pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/13 "2022-07-20T23:42:50Z")
If some 1.7 feature is crucial for your packages, I would drop the support of older (1.6) versions. Many packages support only the latest stable release.
Then, what’s good is to keep one eye at the next stable release. More than that is a luxury that’s only justified by very specific reasons.
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [July 21, 2022, 1:43am UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/14 "2022-07-21T01:43:57Z")
One topic that I have not seen discussed here is semantic versioning: [https://semver.org/](https://semver.org/) .
> Given a version number MAJOR.MINOR.PATCH, increment the:
>
> 1. MAJOR version when you make incompatible API changes,
> 2. MINOR version when you add functionality in a backwards compatible manner, and
> 3. PATCH version when you make backwards compatible bug fixes.
I would really like to see new functionality added to Julia in a backwards compatible manner, so I hope that we see many minor version releases to come. The long term support model also provides which minor release will continue to receive bugfixes and thus minor versions.
The semantic versioning scheme also clearly indicates that any new functionality that is added in a backwards incompatible manner is a violation of the above rules and thus a bug.
---
### Author:  [@andreasvarga](https://discourse.julialang.org/u/andreasvarga)
#### Post date: [August 1, 2022, 9:30am UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/15 "2022-08-01T09:30:47Z")
This question is relevant for my work to develop a new package [PeriodicSystems](https://github.com/andreasvarga/PeriodicSystems.jl), where I am relying on a compiled Fortran library [SLICOT](https://github.com/SLICOT/SLICOT-Reference) for which a [binary wrapper](https://github.com/JuliaBinaryWrappers/SLICOT_jll.jl) has been created by the courtesy of Ralph Smith. While version 5.7 of the library worked for Julia 1.7 and apparently, “by miracle” also on the nightly version (i.e., Julia 1.8), the last version 5.8 works only with Julia 1.7 (see [#4969](https://github.com/JuliaPackaging/Yggdrasil/issues/4969) ). Apparently maintaining compatibility of Fortran libraries with several Julia versions is not automatically supported, so for any new version of Julia new wrappers should be included (a not very straightforward fix would be as proposed in [#4770](https://github.com/JuliaPackaging/Yggdrasil/pull/4770)). It would be nice to have this process automated, since in this moment I am really stuck in version 1.7 of Julia.
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [August 1, 2022, 12:16pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/16 "2022-08-01T12:16:55Z")
> [@andreasvarga](#):
>
> While version 5.7 of the library worked for Julia 1.7 and apparently, “by miracle” also on the nightly version (i.e., Julia 1.8), the last version 5.8 works only with Julia 1.7 (see [#4969](https://github.com/JuliaPackaging/Yggdrasil/issues/4969) ).
As of this moment (August 1st, 2022), **Julia version 1.7.3** is the **latest stable release** , and **Julia 1.6.7** is the latest **long-term support** release. Most applications involving production code should be using either version 1.6 or 1.7 right now depending on the requirements for stability and support.
There is a **Julia 1.8-rc3** (release candidate 3) available right now. The 1.8 beta and release candidates are meant exactly for the purpose of testing. The Julia 1.8 code was branched several months ago in February 2022. This includes package and library integration. That is we are actively seeking feedback to see if that version is compatible with currently applications. Once released Julia 1.8 will become the new stable release and support for Julia 1.7 will eventually end. Support for Julia 1.6 will continue until the next long-term support release.
The nightly releases are unstable. They represent the bleeding edge of development. Changes integrated in a day to day basis may break code. These are meant as development previews only in order to catch potential issues early. This code will likely be eventually released as **Julia 1.9** , although a Julia 1.9 branch has not yet been created. Some of these changes may eventually get backported to the _long-term support_ release and the latest _stable_ release.
Most of us should be using Julia 1.7 or maybe Julia 1.6 at the moment, while those of us doing development should be testing Julia 1.8. Some of us that need long term compatibility should use Julia 1.6.
**If your requirements are that you want Julia to keep working with a certain library over a long period of time, I highly suggest depending on the long-term support release branch, currently Julia 1.6**. That is the only branch where we are trying not to break things while providing maintenance (e.g. patches, security updates) over a long period of time. Support for Julia 1.7 will end eventually after Julia 1.8 is released.
In this specific case, I see that SLICOT\_jll was introduced in January 2022 with compatibility starting at Julia 1.7, so I understand that Julia 1.6 compatibility is not an option at the moment.
Continuous integration _is_ the automated system to catch these issues. It seems that system is working in that we are aware of a version 1.8 incompatibility _before_ Julia 1.8 has been released.
> [@andreasvarga](#):
>
> Apparently maintaining compatibility of Fortran libraries with several Julia versions is not automatically supported.
While some processes are automated, I’m not sure if anything around here is “automatic”. We do not have a highly proficient AI system writing Julia for us at this time. The main “automatic” mechanism we have to do not break things is the **long-term release** by simply not adding new features that may break things to the 1.6 branch.
In this specific case of SLICOT\_jll, @giordano [recommended](https://github.com/JuliaPackaging/Yggdrasil/issues/4969#issuecomment-1146836975) a fix similar to [#4770](https://github.com/JuliaPackaging/Yggdrasil/pull/4770) as you noted. However, there is only one Mosè Giordano. **If you would like help putting together this fix, I recommend creating a post specifically about that**.
In this case, it seems that you are also involved upstream, which is very helpful. This would allow us to coordinate a patch release, SLICOT patch release version 5.8.1 , that is compatible with Julia 1.8.
---
### Author:  [@andreasvarga](https://discourse.julialang.org/u/andreasvarga)
#### Post date: [August 1, 2022, 1:49pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/17 "2022-08-01T13:49:15Z")
Many thanks for these detailed explanations. The best for SLICOT integration would be of course to have compatibility starting with the LTS version, as well as with the current and future versions. I appreciate very much your help in this respect. If necessary, I could produce a version bump to 5.8.1 for SLICOT itself, just to keep the right correspondence between the versions. Is this OK for you?
---
### Author:  [@mkitti](https://discourse.julialang.org/u/mkitti)
#### Post date: [August 1, 2022, 1:53pm UTC](https://discourse.julialang.org/t/too-many-julia-versions/84538/18 "2022-08-01T13:53:40Z")
We should discuss this via
[https://github.com/JuliaPackaging/Yggdrasil/pull/5259](https://github.com/JuliaPackaging/Yggdrasil/pull/5259)
or to start a new thread on Discourse rather than continuing to use this “solved” post. I’m just a Julia community member in this context. I have no special authority or decision making capacity.
Perhaps we could ask a moderator to fork these last few posts into a new forum post?