I've implemented 2.3 support with this PR. This was not a particularly easy task, as there are a number of inconsistencies in the project layout. It is also not easy to see the differences between the 2.2 and 2.3 code paths. I have a suggestion to refactor this repository such that the layout uses versions at the top level, e.g. something like:

common
v2/v2_1
v2/v2_2
v2/v2_3
v2/v2_3/idsearcher/...
v2/v2_3/json/reader.go (with a `Read` function)
v2/v2_3/json/writer.go (with a `Write` function)
v2/v2_3/rdf/reader.go (with a `Read` function)

Where each version contains all the version specific files. This avoids files growing uncontrollably like the idsearcher as every version increases (there are a number of files like this). It's also unclear when implementing a new version exactly which files need to be modified vs. copied.

There are also inconsistencies like the json package containing a writer and parser but separate packages for tvloader and tvsaver, there should be a common pattern here (I think the json package having a reader and writer is the better pattern). If things are split up by version, then this becomes even easier, as you just reference <version>/<format> and have access to a read and write functions and they don't even have to be renamed (just Read/Parse and Write), so these function names with 2_2 and 2_3 aren't things that show up in the diffs between the versions.

If all the code specific to a version was within a specific path, adding a new version would be as simple as copying the previous one and making appropriate changes. It would then be easy to see the differences between them using something like: diff v2/v2_2 v2/v2_3 --ignore-matching-lines='package v2_.'

This means for any consumer, all they would need to do is update the paths, like from something like v2_2 to v2_3, the other function calls would remain the same.

I would be happy to take on this refactoring if it is something that might be accepted.