[VOTE] Releasing Orekit 10.0 from release candidate 1

This is a VOTE in order to release version 10.0 of the Orekit library.
Version 10.0 is a major release.

Highlights in the 10.0 release are:

  • Security: fix possible denial of service when loading itrf-versions.conf
  • Specialized GNSS propagators
  • Propagation in non-inertial frames
  • A new Ionosphere model
  • Modeling phase measurements
  • LAMBDA method for ambiguity resolution
  • Shapiro effect for range measurements
  • Improved documentation
  • Several other features and bug fixes

The release candidate 1 can be found on the GitLab repository as
tag 10.0-RC1 in the release-10.0 branch:

The release notes can be read here:

Maven artifacts are available at

The votes will be tallied in 120 hours for now, on 2019-06-26T07:00:00Z (this is UTC time).

+1 for the release!
I have checked signatures, content, tag and rebuilt/tested from the tag.

I only have one remark. In the maven artifacts, the orekit-10.0.source-jar and its signatures files could have been removed before closing the staging repository, so only orekit-10.0-source-jar and its signatures files (the difference is a dot instead of a dash in the name after the version number. The spurious file is created due to the configuration of a maven plugin, I was never able to prevent its creation and generally have to remove it manually. There is no harm in having this additional artifact, so don’t need to run a new release candidate.

1 Like


Working on the python wrapping I ran into some issues with visibility. In the AbstractGaussianContribution (and field version) there is a protected abstract getLLimits(SpacecraftState state, AbstractGaussianContributionContext context), where it seems like the AbstractGaussianContributionContext is not specified as I understand it defaults to private, and thus cannot be accessed? Maybe this abstract class is not for general usage outside DSST, but then we should mark it as such?

Hi again,
There seems to be a static variable definition in LazyLeapHolder that requires that the orekit-data is setup at initialization (TimeScalesFactory.getGLONASS()) as it is depending on getUTC()

private static class LazyLeapHolder {

     * Reference epoch for GLONASS four-year interval number: 1996-01-01T00:00:00
     * GLONASS time.
    public static final AbsoluteDate GLONASS_EPOCH = new AbsoluteDate(

This gives problems in the python wrapping as the environment is not yet set up when the wrapping is performed.

We had some similar issue before, on getUTC() for the 9.3 release in GlobalPressureTemperature2Model

I will fix these two issues. Maybe we shall do a release candidate 2 ?


from me

If a release candidate 2 is performed, perhaps you could also upload the orekit-10.0-src.zip archive and its signature files alongside with the generate site to the staging directory so we can review it is in sync with the git tag. This file is slightly different from the maven artifact orekit-10.0-sources.jar. It is more complete and contains all build and configuration files, whereas the maven artifact only contains sources for the sake of debugging within an IDE. The src.zip archive is generated when running mvn assembly:single.

Thanks everyone for all the testing. I will be creating a new release candidate to address all the issues mentioned here and #566. If you haven’t had a chance to test it yet please post any bugs/issues you find here so I can include them in RC2.


We noticed that the class diagrams generated in the site are very tall. This is a known problem due to a bug in graphviz, which is called by plantuml to render the graphs. This has been identified more than 3 years ago (see https://forum.plantuml.net/?qa=4531/possible-bug-with-relation-in-rectangle-screenshot and the plantuml developer did notify the graphviz project about the issue, but up to now it has not been fixed.
The solution is to downgrade graphviz to version 2.38. On my Debian computer, I use 2.38.0-19+b1 and put it on hold so it is never upgraded automatically.

+1 for the release

Just one very minor remark, the FAQ page of the maven site would need a small update at § “What are Orekit dependencies?” in order to update dependencies to Hipparchus 1.4 and 1.5 for Orekit 9.3 and 10.0.

Issues #564 and #565 are fixed in develop branch.

+1 for the release

OK, looks like the updates are done. I’ll make a new RC and a new thread for it.

Thanks for the updates to the identified issues, the python version builds fine now and the python test suite runs.

Many thanks, +1 for release from my side.

Finally had a chance to review. +1

Hi all,

I think that I found a small typography issue on org.orekit.gnss.Frequency.java.

/** GLONASS, "G2" (1246 MHz). */
R02(SatelliteSystem.GLONASS, "G2", 1246.0 / 10.23),

/** GLONASS, "G3" (1202.025 MHz). */
R03(SatelliteSystem.GLONASS, "G2", 117.5),

The name “G2” is given for both R02 and R03. There is a public method getName() to access the name of the frequency. So the user can be impacted by this issue.