This topic was discussed during the METplus All Hands meeting on April 24, 2024 and documented in this section of the METplus Engineering meeting notes. Each METplus coordinated release consists of a collection of METplus component releases. The integration testing performed in METplus (for all METplus components) and METviewer (for METplus-Analysis components) needs to know which component versions correspond with each other.
Currently, METplus uses numerical offsets to compute corresponding component version numbers. METplus version X.Y corresponds to:
MET version X+6.Y
METviewer version X.Y
METplotpy version X-3.Y
METcalcpy version X-3.Y
METdataio version X-3.Y
While this logic does work, it does NOT work for METexpress which releases on a different cycle. And these relationships may break in the future depending on future funding levels. Note also, that this logic is not currently well-implemented for handling METviewer dependencies.
The METplus team decided that it would prefer to move from a numerical offset solution to a table lookup. Recommend adding a Python file to the METplus repo to define a table for all prior METplus coordinated releases along with utility functions to parse that table. Also consider how these version dependencies relate to the manage-externals and avoid duplication of logic as much as possible.
[ ] Define a table with 7 columns (one each for METplus, MET, METviewer, METplotpy, METcalcpy, METdataio, and METexpress) and 1 row for each prior coordinated release.
[ ] Define a utility function that...
Takes as input a current component and version number.
Takes as input a requested METplus component name.
Takes as input a requested version "type", such as release version number (e.g. vX.Y.Z), branch name (e.g. main_vX.Y or develop), or DockerHub tag (e.g. MET-11.1-latest).
Provides as output the corresponding version name.
Many questions remain:
How to get the latest bugfix number for the vX.Y release? Perhaps use a vX.Y-latest GitHub tag? And define a GitHub action to auto-update the vX.Y-latest tags?
When should develop be returned? And what about beta and rc releases?
What about DockerHub image names?
[ ] Once this functionality exists, update METplus to make use of it.
[ ] Remember to update the METplus Release Guide to include updating this coordinated release table.
[ ] Define a METviewer issues to retrieve this table lookup from the METplus develop branch and make good use of it.
The goal throughout is avoiding hard-coding METplus component version dependencies and instead define that logic in a single spot.
Acceptance Testing
List input data types and sources.Describe tests required for new functionality.
Time Estimate
3 days?
Sub-Issues
Consider breaking the new feature down into sub-issues.
[ ] Add a checkbox for each sub-issue here.
Relevant Deadlines
List relevant project deadlines here or state NONE.
Funding Source
Define the source of funding and account keys here or state NONE.
Define the Metadata
Assignee
[x] Select engineer(s) or no engineer required
[ ] Select scientist(s) or no scientist required
Labels
[x] Select component(s)
[x] Select priority
[x] Select requestor(s)
Projects and Milestone
[x] Select Repository and/or Organization level Project(s) or add alert: NEED CYCLE ASSIGNMENT label
[x] Select Milestone as the next official version or Future Versions
Define Related Issue(s)
Consider the impact to the other METplus components.
[ ] Submit a pull request to merge into develop.
Pull request: feature <Issue Number> <Description>
[ ] Define the pull request metadata, as permissions allow.
Select: Reviewer(s) and Development issues
Select: Repository level development cycle Project for the next official release
Select: Milestone as the next official version
[ ] Iterate until the reviewer(s) accept and merge your changes.
Describe the New Feature
This topic was discussed during the METplus All Hands meeting on April 24, 2024 and documented in this section of the METplus Engineering meeting notes. Each METplus coordinated release consists of a collection of METplus component releases. The integration testing performed in METplus (for all METplus components) and METviewer (for METplus-Analysis components) needs to know which component versions correspond with each other.
Currently, METplus uses numerical offsets to compute corresponding component version numbers. METplus version X.Y corresponds to:
While this logic does work, it does NOT work for METexpress which releases on a different cycle. And these relationships may break in the future depending on future funding levels. Note also, that this logic is not currently well-implemented for handling METviewer dependencies.
The METplus team decided that it would prefer to move from a numerical offset solution to a table lookup. Recommend adding a Python file to the METplus repo to define a table for all prior METplus coordinated releases along with utility functions to parse that table. Also consider how these version dependencies relate to the manage-externals and avoid duplication of logic as much as possible.
The goal throughout is avoiding hard-coding METplus component version dependencies and instead define that logic in a single spot.
Acceptance Testing
List input data types and sources. Describe tests required for new functionality.
Time Estimate
3 days?
Sub-Issues
Consider breaking the new feature down into sub-issues.
Relevant Deadlines
List relevant project deadlines here or state NONE.
Funding Source
Define the source of funding and account keys here or state NONE.
Define the Metadata
Assignee
Labels
Projects and Milestone
Define Related Issue(s)
Consider the impact to the other METplus components.
New Feature Checklist
See the METplus Workflow for details.
feature_<Issue Number>_<Description>feature <Issue Number> <Description>