Update L3 repo to take in new science file version - Card 3295

[tech3371]

Summary

Similar to imap_processing repo, update areas that parses version to be able to ingest new science version, MMM.mmmm

Requirements

The more specific the better.

• [ ]
• [ ]

Related tickets

No response

[pleasant-menlo]

Holding off on implementation until the upstream plans about major versions are a little more finalized.

L3-specific points to consider:

• How does GLOWS L3b+ know which major version to output? Match the major version from L3a?
• How do L3 maps determine major version? Match the major version from L2?

[jtniehof]

* How does GLOWS L3b+ know which major version to output? Match the major version from L3a?

IMAP-Science-Operations-Center/sds-data-manager#1448 requests the ability to query output major version.

* How do L3 maps determine major version? Match the major version from L2?

I think we'd do this as for the other products; there's a specified major version output and we may or may not bump it based on changes to the L2, or other changes. That can be queried as above, but the L3 is a simpler case of (usually) a single output. In that case the desired output version will be passed in as part of the dependency json. See first comment in IMAP-Science-Operations-Center/imap_processing#3266 for the planned format.

See working notes for further background.

[jtniehof]

IMAP-Science-Operations-Center/sds-data-manager#1449 would ensure that all the outputs get desired versions assigned in the dependency JSON. However, since it only specifies one per output product, it wouldn't work for our use case, where we may be making multiple CRs of b and c, and almost always multiple repointings of e. It might be enough to tell the desired major version without a special query, though.

[jtniehof]

IMAP-Science-Operations-Center/imap_processing#3313 is potentially useful reference