Do you think that it could useful to generalize the API of DistanceMeasure interface by using an interface instead of a double[] array in the compute() method ?
The idea is to have implementations that can contain more than a double[] array of values. For instance, the uncertainties related to the values
Another possibility is to use Clusterable instead of double[] since the DistanceMeasure interface is in the clustering package. But I also think that DistanceMeasure could move to another module, like core, since it is generic. As a result, Clusterable could not be used and a new interface should be created. (Clusterable could extend this new interface)
To do the change, I’ll need to update Hipparchus version from 4.1-SNAPSHOT to 5.0-SNAPSHOT. It means that next version would be a major one.
I don’t think it’s an issue since we have opened discussions on upgrading Hipparchus’ java version to 21/25. In other words, a major release is already targeted.
There is already a bunch of non API breaking contributions so I thought we could stick to Hipparchus 4.1 for Orekit 14.0
Doesn’t mean we can’t release Hipparchus 5.0 very soon after. It the breaking changes don’t impact Orekit, users can override in their POM the version compared to the one inherited transitively. That’s kind of why I opened a thread about 4.1 a while ago. What do you think?
About the java version, as far as I’m aware, the PMC has never acted the fact that Hipparchus is upgrading beyond 8…
I don’t see a problem with it; I’m just wondering what timeframe we’re talking about: a few days, weeks, or months. If the timeframe is short, I don’t see any issue with having Orekit 14.0 depend on Hipparchus 4.1.
If, on the contrary, the timeframe is longer, I don’t see why Orekit 14.0 couldn’t depend on a version 5.0 of Hipparchus.
