version/revision handling

[Optiligence]

heidelbrain, and annotation files currently get version python also has revision new version implies reset settings revision is only available when built within a git repo

[my-tien]

So, Heidelbrain is interested in the version to ensure the tracer is using an up-to-date K. But it’s possible that the up-to-date K for the task isn’t released in which case the revision would be needed. It doesn’t hurt to send both values in case revision isn’t available.

Being able to load settings from previous versions becomes more necessary the faster we release (^^) especially because users have to recollect all their datasets and generally I find losing settings very annoying. So I’m all for a general KNOSSOS.ini and when introducing new features that invalidate previous entries, we give them new names, as has been done before. The .ini name can be specified in the QSettings ctor.

[Optiligence]

I’m still a bit uneasy about this. So with 1 ini, do we stay at KNOSSOS 5.0.ini, copy it to a KNOSSOS.ini on first start or only use the latter… Revision was introduced as a more fine-grained descriptor, and Heidelbrain/Annotation want this, why do we need Version? Revision could fall back to a constant if built outside git. What should the title bar display (if anything at all)?

[my-tien]

So with 1 ini, do we stay at KNOSSOS 5.0.ini, copy it to a KNOSSOS.ini on first start or only use the latter…

Copy, no? It’s not a big deal, we can check if a KNOSSOS.ini is present and if not try to copy the KNOSSOS 5.0.ini.

Revision could fall back to a constant if built outside git.

Yes, even better.

What should the title bar display (if anything at all)?

I don’t care. I also don’t care about the 5 vs 5.0 question. Maybe someone else has an opinion?