Orekit 11.3 released, what should be next?

Dear Orekit community,

Orekit 11.3 was released 2 weeks ago. In order to start the new developments, the Orekit team would like to have your opinion on what should be the next release?

They are two possibilities:

  • A new minor release (i.e. 11.4). It would include bug fixes and new features.
  • A new major release (i.e. 12.0). It would include bug fixes, new features and API changes since the last major release.

Minor releases usually take few months (i.e. 3-4) to be done. Major releases usually take more time (i.e. 6-7 months) because Orekit developers want to be sure to clean all the API who need updates.

Current status of the opened issues and merge requests is as followed:

It is important to note that these numbers only reflect a first idea of the release’s program. Indeed, the easy answer here is to say that the next release should be a major because they are more issues. But, the real answer must be based on the users needs

So, what should be the next version?

Best regards,


Thanks Bryan for the projections.
The fact is that there’s quite a number of patch releases tagged issues too, including some important stuff in my opinion regarding analytical and semi analytical propagators. So them plus all the minor release ones sums up to a fair amount of work I think, tentatively pushing back the attempt at a major release for later.
That also brings up a question: could the new collision package be included in a minor release?
If no it’d be good to know with a show of hands if Orekit’s users are interested or not, as this would weight in the decision.


Yes, I agree. I didn’t speek about patch releases because they don’t impact the developers’ decision about breaking the API or not. In other words, they don’t impact the fact of having a next minor or major release. But yes, me must have patch version of Orekit 11.3.
I would like to have one patch soon including the fix for DSST orbit determination, documentation fixes, and the fix for the conversion from mean to eccentric anomaly.
Another patch release could be done for analytical propagators.

Good question for @Vincent.


I have talked about this with @MaximeJ just yesterday and even though it should technically be in a major release because of an API break in LOFType. We could get around this issue by tagging the old methods as deprecated while adding the new ones.

To be more specific, it is because of the addition of the LOF interface as I move all the methods from LOFType to this new interface. Hence the API break because of the static methods rotationFromLOFInToLOFOut and the transform equivalent.

However, I still need the thoughts of most of the developers regarding the current collision package architecture here :sweat_smile:.

Good day to everyone :wave:,

I would prefer going for 12.0 since there a many issues and merge request waiting for it.
And I think it’s frustrating for contributors to wait for months before their contribution is merged.

But if collision package is an urgent feature I’m not against going for 11.4 as soon as it is ready.

In the meantime, as Bryan said, we can add any number of patch releases to fix bugs.

I would prefer a 12.0 version either, we have several deprecated things I would like to remove.

Based on the replies, next version will be a major release.
(we will also try to release patches for 11.3 version)


A major release it is then!
It’s a shame that nobody seems enthusiastic (or dares to express their enthusiasm) about the so-called collision package, @Vincent is working hard on it (and on so many other things, many thanks to him!).
And I just saw that a significant improvement on the DSST propagator has already been pushed to the develop branch, thank you @bcazabonne!



Thank you!

I think a lot of people don’t dare to answer because they may consider their opinion not very legitimate compared to a developer’s opinion. The important thing is that all opinions count, especially those of users.

Thank you @Serrof :smile:, you’ve been a great help on most of it !

Personally i think that we have enough materials for a 11.4 but as @MaximeJ said, there are lots of merge requests waiting for 12.0…

Also, adding the collision package in a 11.4 would mean marking some methods as deprecated for the sake of it so I’m kinda torn on this.

Hello the community,

We spoke internally in the CS orekit team and we agreed that we should push for a 12.0 version. For the planning, we wanted to do it T1 2023, and to share the work on the merge requests and review of somes issues with the community, so the CS team could perform the release just after.

So maybe starting to “freeze” the devs and any new things/issues could be tagged as 12.1 (if the board agree with the 12.0 of course) ?