Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ENH: Automatically add atef version number to checkouts #199

Open
tangkong opened this issue Aug 30, 2023 · 4 comments
Open

ENH: Automatically add atef version number to checkouts #199

tangkong opened this issue Aug 30, 2023 · 4 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@tangkong
Copy link
Contributor

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

@tangkong tangkong added enhancement New feature or request good first issue Good for newcomers labels Aug 30, 2023
@klauer
Copy link
Contributor

klauer commented Aug 30, 2023

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
Copy link
Member

ZLLentz commented Aug 30, 2023

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
Copy link
Contributor Author

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
Copy link
Member

ZLLentz commented Aug 30, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants