Documentation versioning and fuller config docs

[python3Berg]

Given the need for a converter to move config files from 3.2 to 3.3, should we not also apply the same diligence to the documentation. As I start on a path to move from 2.3 to now 3.3, I have found that documentation is unclear as to which version it addresses and often the explicit examples fail in a real config file. The first example is with NER labels. After init labels, an ner.json file is created. When adding

[initialize.components.ner.labels]
@readers = "spacy.read_labels.v1"
path = "corpus/labels/ner.json

✘ Error parsing config section. Perhaps a section name is wrong?
initialize -> components -> ner -> labels Section 'ner' is not defined

There are other examples where the documentation is suspiciously inconsistent with the generated full config. It would be great if we knew exactly which version of spacy the documentation was speaking to...that the documentation examples were always tested vs. the version it is associated with and that the config file overall had a more complete documentation so we were not scanning through low level code to reverse engineer a setting.

I love spacy, but have felt the documentation often misses important details that are ever more important given the "almost never" policy of backwards compatibility.

[polm]

Sorry this error isn't clear, but I think what's happening here is just that you have something that looks like this:

[initialize.components]

[initialize.components.ner.labels]
@readers = "spacy.read_labels.v1"
path = "corpus/labels/ner.json

The error is due to the way the config format works - it doesn't create intermediate blocks by default, so you have to do this:

[initialize.components]

[initialize.components.ner]

[initialize.components.ner.labels]
@readers = "spacy.read_labels.v1"
path = "corpus/labels/ner.json

With that change I suspect you can resolve the error. The error could definitely be clearer in this case, and we do include the intermediate block in the docs but it's easy to miss.