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…?
1 Like
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.
10 Likes
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).
1 Like
OK, that makes sense. I thought 1.7 was still being developed (1.7.3 just appeared, I believe?).
Until 1.8 gets released, 1.7 will get bugfixes.
1 Like
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.
2 Likes
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.
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.
Oops, you’re right. It was 1.6.7.
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.
5 Likes
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.
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.
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.
2 Likes
One topic that I have not seen discussed here is semantic versioning: https://semver.org/ .
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards compatible manner, and
- 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.
2 Likes
This question is relevant for my work to develop a new package PeriodicSystems, where I am relying on a compiled Fortran library SLICOT for which a binary wrapper 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 ). 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). It would be nice to have this process automated, since in this moment I am really stuck in version 1.7 of Julia.
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.
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 a fix similar to #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.
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?
We should discuss this via
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?