m-mohr
commented
7 months ago With every release we check the processes according to the current procedure:
The *.json files provide stable process specifications as defined by openEO. Stable processes need at least two implementations and a use-case example added to the openEO Community Examples repository or consensus from the openEO PSC.
I did the checks for 2.0.0-rc.1 and at that point sar_backscatter did not qualify (I haven't checked whether that's the case right now). We'll check ths again for the next release.
If you think a process is not experimental in your implementation, you can change the experimental flag in your process definition regardless of what the process specification says. That's by design, you don't need to wait for the new release.
and has remained unchanged since we defined it more than 2 years ago.
That alone is not a good argument. There are a lot of experimental processes that have not changed since years and (for good reasons) still don't qualify.
We are no longer at a point where we can freely change the definition without impacting operational projects that depend on openEO, so we should remove this flag.
I also don't fully agree with this. Surely, we should be careful and thoughtful as always. No one breaks things for fun. But there may always be one implementation of a process that has this issue, but that should not prevent to do potentially necessary changes to the specification. Keep in mind, backends could still use the old specification regardless of upstream changes.
sar_backscatter
this process is one of our most often used processes, and has remained unchanged since we defined it more than 2 years ago. A user asked me why it is still marked as experimental, and it's indeed weird. We are no longer at a point where we can freely change the definition without impacting operational projects that depend on openEO, so we should remove this flag.