-
Notifications
You must be signed in to change notification settings - Fork 37
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
Feature #2562 version lookup documentation and automated tests #2773
Conversation
…e 2nd highest coordinated release version number in the version lookup table. This assumes that the highest version is what is being developed towards
…the component versions lookup table in the METplus repository
…evious location using manage_externals, remove manage_externals config files that are no longer used by the automated tests
…mated tests that have been removed
… and added stubs for other utility descriptions
…ng demonstrated from each example
@georgemccabe I'm trying to wrap my head around this. I see in the bugfix documentation it says to check out develop, and I understand why that would be. But, do we also want to update the main version of metplus/component_versions.py during a bugfix releease? |
@georgemccabe Also, I'll note that the add_next_version_to_lookup.rst file text assumes that the METplus components will always cut a X.0.0 release and then cut a X.1.0 release and then cut a X+1.0.0 release, which may or may not be the case, but it seems simplest to leave as-is, since that it is likely, an account for exceptions as we go along. Is that what you and @JohnHalleyGotway were thinking too? |
@jprestop, I believe we discussed that any logic used to obtain version info would download the script from the develop branch to ensure it is maintained in one place. This idea sounds good in theory, but the details depend on how the script is eventually used and may need to change. If we start using this script and determine that we do need to have an updated list in the main_vX.Y branch, we would need to update these instructions to update the numbers in both main_vX.Y and develop.
|
So far that has been the case and aligns with our current development cycle of 2 releases per year: X.0 and X.1. If this process changes, we will likely have to review more than just this instruction for accuracy.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all of your work on this task and for the discussion. I have reviewed the documentation and ensured that all tests passed. I approve this request.
@georgemccabe I hope you don't mind but I'm going to squash and merge this now, so I can pull these changes into the branch I am working on now. I did not, however, delete your branch, in case you still need it for some reason. Feel free to delete when you're ready. |
Change Summary
Pull Request Testing
Do these changes include sufficient documentation updates, ensuring that no errors or warnings exist in the build of the documentation? [Yes]
Do these changes include sufficient testing updates? [Yes]
Will this PR result in changes to the test suite? [No]
If yes, describe the new output and/or changes to the existing output:
Do these changes introduce new SonarQube findings? [No]
If yes, please describe:
Please complete this pull request review by 11/8/2024.
Pull Request Checklist
See the METplus Workflow for details.
Select: Reviewer(s) and Development issue
Select: Milestone as the version that will include these changes
Select: Coordinated METplus-X.Y Support project for bugfix releases or METplus-Wrappers-X.Y.Z Development project for official releases