ENH: Automatically add atef version number to checkouts

pcdshub / atef

PCDS Automated Test Execution Framework

https://pcdshub.github.io/atef/

Other

3 stars 9 forks source link

ENH: Automatically add atef version number to checkouts #199

Open tangkong opened 1 year ago

tangkong commented 1 year ago

Expected Behavior

There is a field for version in top-level atef files (ProcedureFile, ConfigurationFile) Now that there are actual atef versions, we should fill this information properly. This info could be used to determine whether checkouts can be used, as we add new steps and functionality.

At the moment we work hard to avoid backwards incompatibilities (old checkouts should mostly work), but some checkouts won't work on old versions of atef.

Current Behavior

All versions are 0

Possible Solution

Read the python version

Context

Was thinking about gathering example checkouts

Your Environment

pcds-5.7.3, atef v1.0.0

klauer commented 1 year ago

All versions are 0

This is the "serialization"/dataclass version and not really the atef version. The idea is that we should bump it every time there's an incompatible difference in what's being loaded. I envisioned it as a marker for us to say, in the future, if we wanted to support older formats (or not). e.g., "Check version number, instruct apischema to load older/newer format"

It could be replaced with an atef version number, but that would not indicate compatibility (without an extra/more complicated version check like the above, anyway)

ZLLentz commented 1 year ago

it's not so far-fetched to want both of these numbers for different reasons I guess you were envisioning this as strictly backwards-compatibility check, not a "some new classes/options were added" sort of check

tangkong commented 1 year ago

Ah right, I can rephrase this as wanting an additional piece of information. In addition I think we probably want to actually update this number somehow... (seems like it'd have to be hard coded at this point?)

To clarify things (mostly for myself):

the current version points to "serialization" version, where older files might not be compatible with newer dataclass schema.
- To make this compatible, we'd have to keep old versions of the dataclasses and look to this version when we attempt to load a file
an atef version would point to atef's version, where newer files (with newer steps) might not be compatible with older versions of atef
- Newer files will never be compatible with older versions of atef, if they are using the full, modern feature suite.

ZLLentz commented 1 year ago

ironically, adding an atef version number would probably be the first serialization version number update