Orekit 13 Release?

Orekit development
1

Hi,

I’ve seen several references to the 13.0 release coming soon on the forum. And Hipparchus 4.0.1 is out. How soon should we expect the Orekit 13 release? weeks or months? Just trying to plan for it. And there are many nice new features in it. :slight_smile:

Thanks!
Evan

2 Likes
2

Hi @evan.ward

Weeks, I hope…

1 Like
3

Hi Evan,

I think the release is very very very overdue. We’re over a hundred issues addressed. We could have released last year to be honest. But since I don’t master the release process I keep quiet. In the future though it’d be nice to have some sort of tentative calendar, at least for major releases. Ultimately the project is driven by individual contributions so there’s always an aleatory element, so nothing is carved in stone.

Cheers,
Romain.

1 Like
4

Hi,

Thank you @evan.ward for starting this conversation :wink:
I do agree with @Serrof this release is long overdue :wink:
But the 13.0 milestone is almost complete. I propose that we don’t add new issues to it.
The two unstarted issues are the one about the translations and a documentation one that should be quick to fix.
I can send the translation email next week.
Once the three ongoing issues are closed, I think we’re good to go for the release!
What do you think?

Cheers,
Maxime

1 Like
5

I will probably add an issue for renaming IRNSS into NavIC as it will affect some enumerates.
I will also probably change slightly an API for Rinex to prepare for Rinex 4.02 (there are new navigation messages), even if we postpone support for Rinex 4.02 to 13.1 ; at least the API will be ready, even if the list for new navigation messages will always be empty.

1 Like
6

There are 12 open merge requests, some of which are quite old. From a community management point of view, it’s not a good practice to leave these MRs open, without updating or interaction.

7

Hello,

I have some responsability in this issue :sweat_smile:, i should be more available in April to finish my MR.

Cheers,
Vincent

8

As this is a major release, I’m guessing that this new version introduces some API breaks. For the migration and adoption of Orekit 13 to go smoothly, we need to highlight them and, if possible, explain to the community the right way to handle them.

9

It is already here: upgrading from 12 to 13

3 Likes
10

You’ve probably noticed that, in GitLab, a “due date” can be defined for a milestone. This attribute is never filled in. :slight_smile:

As this date is not “contractual”, but simply a projection provided to the community, a first step in the direction you suggest would probably be to set this date. If setbacks and delays lead us to revise it, that’s fine. But, from my humble point of view, it’s important for everyone to have the calendar objective in mind.

11

Wonderful :heart:

12

Everything I wanted to add to 13.0 has been finished.
From my point of view, we could finalize the release.
@MaximeJ, would you mind contacting the translators?
Is anyone volunteering for managing the release?

1 Like
13

Thank you very much @luc !!

Email sent.

Isn’t it a bad omen to be the releaser of v13 ? :wink:

1 Like
14

I may need to add a last minute issue today…

15

I noticed that a long-awaited feature – “Add support for mailmap configuration” – should be available in the next GitLab release (see “[Feature flag] Rollout of check_for_mailmapped_commit_emails”). Could you therefore merge the request “#645 – Update and reduce the contributor alias file to the minimum required”?

16

Job done! :ninja:

1 Like
17

Nice, the feature flag seems to be already activated in GitLab 17.10.1:

3 different authors “Bryan Cazabonne” in the list of Git commit authors, but only one now in the contributor analytics:

https://gitlab.orekit.org/orekit/orekit/-/graphs/develop?ref_type=heads

18

In fact, what I needed was already added more than one year ago… by myself, and exactly for the same reason I need it now. So no more issues from me (at least for now).

2 Likes
19

Hi all,

I’m really looking forward to version 13.0.

However, I read that Tropospheric related changes, the GroundStation is required to provide a PressureTemperatureHumidityProvider, and some Tropospheric models are allowed to pass a PressureTemperatureHumidityProvider.

The MendesPavlisModel and MariniMurray are two commonly used correction models in laser ranging. In the method pathDelay, the MariniMurray model uses the incoming parameter weather (obtained by GroundStation), while the MendesPavlisModel model ignores the the incoming weather parameter and instead use the PressureTemperatureHumidityProvider that was passed in during that model’s construction, which would make it confused.

Is it possible to be consistent? I hope this doesn’t disrupt the release.

20

You are right.
In fact the weather parameter is intended for use with the mapping function, but many models simply ignore it.
Could you open an issue on the forge for this, with a target version at 13.0 so we don’t miss it?
I guess we will have to change the signatures of the TroposphereMappingFunction interface.