Change in edm4hep.yaml for consistent naming

[FinnJohannsen]

BEGINRELEASENOTES

• Changed the name of one VectorMember of edm4hep::track from subDetectorHitNumbers to subdetectorHitNumbers to be consistent with other spellings of the word subdetector in the yaml file and in LCIO.

ENDRELEASENOTES

[jmcarcell]

I'm not aware if this is standard or not but a change like this affects other repos, in this case it would be k4EDM4hep2LcioConv and k4MarlinWrapper that would need the same rename.
In EDM4Hep I only find one case like this: subdetectorEnergies with lower case and in LCIO it looks like the rule is most of the time subdet when the variable starts with sub and Subdet when there is something before.

[tmadlener]

Yes, this definitely affects other repos as well, plus it also requires schema evolution support from podio. So for now, we will just leave this open, and then go for a concerted effort with all other repositories affected.

[tmadlener]

As discussed during todays meeting. This does in fact not (yet) need schema evolution since the branch names are index based in all the files that have been written up until now. This will need some changes in the converters probably, but they should be fairly straight forward.

[tmadlener]

To avoid too many problems in dependencies, we need to tag EDM4hep pretty much immediately after this has been merged.

[andresailer]

If we increment the patch version to 99 (and set to correct version for the tag), we should be able to compare against the last tagged version even with the master branch?

[tmadlener]

Yeah that should work, but a new tag would be nice in any case, since we don't have a tag yet with the schema_version in the yaml file.

[tmadlener]

In a local build of the key4hep stack this breaks a few more things than just the converter. I will prepare PRs to fix those as well.

[tmadlener]

The PRs in CEPCSW and k4LCIOReader should make this work smoothly once they are merged.

[jmcarcell]

Why the CMakeLists.txt changes though? Those are unrelated and not needed...

[tmadlener]

I think they are necessary in some of our CI workflows for a cleaner test environment (or at least one that has the "underlying" environment late enough in order to not pick it up). I must confess, I overlooked these when merging, but I don't think they harm us either.