I was doing some testing with the 10.3 release recently comparing the reference frame stability with previous releases of Orekit. (Arguably I should have done this before 10.3 was released.) I was quite surprised when I found differences of 50 cm when comparing ephemerides generated with previous versions of Orekit. These differences seemed to be much larger than the assumptions in Orekit’s frames, even with
simpleEop. Investigating further the discrepancies only seemed to appear when comparing ephemerides in OEM format, so perhaps not a frame issue at all. The 10.3 change log didn’t mention any backward incompatibilities, neither did the release vote. On further investigation it seems to be due to the changes for #686 (user defined formats in OEM) changing behavior by discarding significant digits by default, with no way to regain the previous behavior.
The point of this message is not the past. (I’m assuming the contributors had the best interest of the Orekit community in mind.) The point of this message is instead to see if we can improve the process for the future. I think Orekit’s current policy of not being too strict with compatibility leaves much undefined. Are changes in behavior with the same interface ok? Is it the developer’s responsibility to notify about incompatibilities or the user’s responsibility to figure out what changed?
I think it is good for Orekit that we are not too strict with compatibility. I also think it would be good to have some guidelines about communicating about incompatibilities in minor releases so that the community and contributor can know their responsibilities. Perhaps a good guideline would be to note incompatible changes as such in the change log, release vote, and release announcement. That way there will be better communication throughout the community about them and the community can discuss them before the release.