(sorry for duplicates, forgot to "reply to all")
Hi Christian
In our case, using BaseX as a pure XQueryProcessor with no interactions with a database, we could mix different versions of BaseX in different applications on our application-server (Apache Karaf) without having warnings in the log about incompatible options files. If we for instance run 7.8 in one application and 8.2 in another we get warnings from the 7.8 app about unrecognized options. And the 8.2 version might require an option that is not part of the 7.8 version that will trigger a warning about that. Both apps will then rewrite the file to match it's specification.
Today we fix this by upgrading all our applications to the same version since we are a bit concerned about the effects of multiple applications fighting over the same file.
For us the major advantage would be not having to do this upgrade of applications using an older version if we deploy a new/updated application using a newer version of BaseX.
I guess the way we use BaseX is not the most common way. But this would for sure help us a lot.
A suggestion for the future, with out knowing the implications, could be to split the QueryProcessor into two implementations where the first continue to be database aware and the other not. The later version would then behave more like the Saxon QueryProcessor. Having sensible default options and ability to override these on construction (in memory).
Regards,
Johan Mörén