Daniel Woste

1) wouldn't be so easy to detect a problem. We could store the used Sphinx-Needs version in the Sphinx `env` object, and compare with one from the currently use Sphinx-Needs...

I want to close this issue because I see it more as something that should be solved in Sphinx itself. What is described for Sphinx-Needs (inconsistent data, version upgrade, config...

It's not so easy to remove fields from needs-data, as you never know the use cases and if the data may be used for filtering needs. But I also have...

Good point, the output is not configurable and does not support other languages. I'm not sure, if this should be given by a directive option or if a variable in...

I like the PR from a technical point of view, but I'm not a fan of it from a usability point of view. I agree with @David-Le-Nir, that adding this...

> I don't think this is correct; you would remove the needs items (that have negatively-evaluated only_expressions) before any filter strings are processed. Ahh okay, then I have misunderstood the...

Good finding. I think having options for one variant only is not supported. But for sure, it should be. But this means also, later code must check on its own...

Thanks for the bug report. We had similar problems in the past with other sphinx functions and needextract. Reason for this was, that we need to trigger the related sphinx...

Thanks for the issue and I totally understand the problem. `JSON` has been selected as format of choice, as it is simple and supported by several languages out-of-the-box . Also...

> ... it's simply unnecessary to store parts of the needs that do not add information I can't entirely agree in all cases, but to be backward-compatible we can also...