I’m also afraid that making the Orekit 13.0 version the LTS one will:
Cheers,
Vincent
No need to act urgently, we can wait a month or two before officially announcing that the 13 becomes the LTS. 
Well, this forum is public, so some may have already noticed 
But, yeah, I understand, we have not announced it (and not decided either, as the PMC did not vote on such an important topic).
I would also prefer 21 to 17, as the former brings up two very convenient features w.r.t. the latter:
getFirst and getLast on ListswitchHi,
Though I don’t have as much open source experience, it seems to me that the key factor in the success of a LTS version is having a LTS maintainer. The LTS maintainer has the mostly uninteresting job of back porting patches to the LTS version. And the more the development version uses fun new language features (e.g. records) the harder the LTS maintainer’s job becomes. And a five year commitment is significant.
The alternative to having an LTS Maintainer would be to ask everyone that fixes a bug also do the back port of of the bug to the LTS branch. As a developer I would prefer to fix a bug once, rather than several times, using different language features each time. (Perhaps incentive to not use new language features.) This approach would also require contributors to have more git skills and familiarity with multiple Java versions, so would seem to lose much of the benefit of moving to a new Java version. (making development more fun for contributors)
I would support creating an LTS Orekit release if there is a volunteer to be the LTS maintainer, or at least a solid plan for how the LTS would be maintained.
Regarding the next Java version, my personal preference would be to move to Java 21 when the time comes to drop support for Java 8.
Regards,
Evan
Thank you for your feedback @evan.ward, interesting and raises very pertinent points, as always.
I completely agree with you. That is why we should not have a designated “LTS maintainer”. Supporting an “LTS version” should be a shared responsibility / load / pain of all Orekit contributors.
But let’s not lose sight of the main point: if we develop free and open source software, it is not only for ourselves, it is also and above all in the hope that it will be successful and used by a large community (which is the case with Orekit today). And once this software is used by a lot of people, we start to develop and maintain functions that do not correspond to our own needs, but to the needs of other users. I am sure that none of you use all the functions of Orekit and all the file formats that this library supports. But it is this richness that makes Orekit so interesting.
However, as I said, you are absolutely right that providing support for an LTS is a thankless task. So a compromise has to be found on what is done and the duration of the support.
In an LTS, only bugs and security flaws are fixed, no new functions are introduced, and the API is not changed. The work is therefore limited, and it is likely that the code affected by these bugs will not change much in the new versions of Orekit (most of the time, it is in no one’s interest to rewrite what already works, at the risk of introducing new bugs).
Honestly, I think that support for this LTS version will require less and less work over time. At the beginning, we will certainly report numerous bugs, which will appear in both the LTS and the new version, but over time, the new bugs will only impact the new version, as the LTS code will mature within a scope that no longer changes.
In addition — and this is undoubtedly the most important point — it is advisable to only modify the code of an LTS when a user reports a bug specifically on that version. If no report is made on that version, it is certainly because no user of the LTS is using the code affected by the bug. So why bother and take the risk of modifying the code?
To conclude, I am a pragmatist: an open source project is based on the goodwill of all its contributors. If at a given moment, nobody wants to make the effort to maintain the LTS version, so be it. It is likely that this will not appear to be very important, neither to the contributors nor to the users. If users suffer from this abandonment, they will always have the choice between:
In my opinion, the contributors to an open source project are even more valuable than the users, especially those who only know how to complain and always forget to say thank you. And I don’t want contributors to be frustrated and condemned to using an obsolete environment to please users who accumulate technical debt and never contribute to the project.
The choice of a LTS is certainly not an ideal one, and it introduces its own problems, which we will deal with in due course as best we can. This compromise seems reasonable to me and preferable to any other strategy.
I agree with you. If no one is willing to contribute, as always, within the limits of their availability and the efforts required, to the maintenance of the LTS, there is no point in even talking about it and the question becomes more binary: do you stay on Java 8 or switch to Java 21?
As for the maintenance plan, the PMC may, with the agreement of the contributors, set out in writing the limits of LTS support (for example, the fact that a bug is only investigated in the LTS when it is specifically reported in that version).
You are absolutely right, I agree with you, except that I don’t want to appoint a specific person to maintain the LTS, nor do I plan to tell any of you what you should do on the project. If no one is willing to contribute, as always, within the limits of their availability and the efforts required, to the maintenance of the LTS, there is no point in even talking about it. The question becomes more binary: do you stay on Java 8 or switch to Java 21?
As for the maintenance plan, the PMC may, with the agreement of the contributors, set out in writing the limits of LTS support (for example, the fact that a bug is only investigated in the LTS when it is specifically reported in that version).
We’re using Orekit and Java 23 at my company, I’ll throw my two cents in:
I’d say to upgrade the next Orekit version to Java 21 in the next major version. Orekit 14 requiring Java 21 doesn’t prevent the userbase that is still on Java 8 to use Orekit 13, so they can still continue to use the library.
Regarding the Java versions, the only painful migration is from Java 8 to anything higher. After that it is not a problem in general to upgrade the versions, though of course there will be exceptions.
I do not think Orekit should start doing LTS versions, since that’s a considerable effort that would be better spend on reducing technical debt (please stop doing == on doubles, please) or developing new features.
Thanks a lot @LordRaptor for your feedback.
We “think that” Orekit users still rely on Java 8, while others, like you, use much newer versions. But we have never conducted a serious investigation into this, so in reality, we don’t know.
That said, we know that users are not always free to choose the Java version because:
But this reality must not prevent us from moving forward. We cannot remain on an antediluvian version of Java indefinitely because there is one user – and only one – of this version somewhere in the world, while everyone else has migrated to more recent versions.
On the other hand, it would not be reasonable to declare that we will adopt the next LTS version of Java – 25 – as soon as it is released in December 2025. This version will not be available on stable systems in the short term, and by adopting it, we would make Orekit difficult to deploy for most users.
We must therefore find a compromise between the wishes of the contributors and the environment of the majority of users. This compromise must be based on a survey: we should ask Orekit users which version of Java they use, explaining that:
I would add that I am wary of entryism, which is a very real problem in open source software, especially when people have an interest in homemade or commercial alternatives. I therefore believe that we should prioritize listening to users who are close to the project, with whom we have been in contact for a long time or who contribute in one way or another (by contributing to the code, but also by reporting bugs or participating in support on the forum).
As I have already explained, maintaining an LTS is not necessarily very difficult. It is enough to accept the fact that:
Of course, everything I have just said is only my opinion and if the contributors are of a different opinion, I will readily agree with them.