Hotfix/203 pcluster dep bug

[hahnd]

Same hotfix branch also merging the change into develop.

• [ ] Do these changes modify the system output in any way? [Yes or No]
  If yes, please describe:
  

Pull Request Testing

• [ ] Describe testing already performed for these changes:
  

• [ ] Recommend testing for the reviewer(s) to perform, including the location of input datasets, and any additional instructions:
  

• [ ] Do these changes include sufficient documentation updates, ensuring that no errors or warnings exist in the build of the documentation? [Yes or No]

• [ ] Do these changes include sufficient testing updates? [Yes or No]

• [ ] Will this PR result in changes to the test suite? [Yes or No]
  If yes, describe the new output and/or changes to the existing output:
  

• [ ] Please complete this pull request review by [Fill in date].
  

Pull Request Checklist

• [ ] Review the source issue metadata (labels, project, and milestone).
• [ ] Complete the PR definition above.
• [ ] Ensure the PR title matches the feature or bugfix branch name.
• [ ] Define the PR metadata, as permissions allow. Select: Reviewer(s) Select: Project Select: Milestone as the version that will include these changes Select: Development to link to the original development issue.
• [ ] After the PR is approved, merge your changes. If permissions do not allow this, request that the reviewer do the merge.
• [ ] Close the linked issue and delete your feature or bugfix branch from GitHub.

[hahnd]

Yes, this was a bug affecting the current production release, so the git flow hotfix procedures were followed and the branch was made from the release tag.

I manually edited the version number to resolve the conflict.

In the future, should we hold off on changing the version number until we create the release branch?

[georgemccabe]

In the future, a single commit can be applied to another branch using the git cherry-pick command.

• Find the commit hash or hashes of the changes that should be applied to the other branch. This can be the commit that results from the squash/merge of a PR if all of the changes from that PR are needed, e.g. 90570361
• Note at least the first 8 characters of the commit hash or hashes
• Create a branch off of the other branch that needs the fix. (develop or main)
• Run the cherry pick command for each commit hash to apply: git cherry-pick <commit_hash> e.g. git cherry-pick 90570361

[georgemccabe]

I think we decided to set the version number X.Y.Z-dev to signify that it is development towards X.Y.Z, then change to X.Y.Z when we create the release. This helps discern whether the state of the code is an actual release or includes partial development towards the next release. This is how we name versions for METplus and it seems to be useful. I'm open to other approaches if another is preferred.

Yes, this was a bug affecting the current production release, so the git flow hotfix procedures were followed and the branch was made from the release tag.

I manually edited the version number to resolve the conflict.

In the future, should we hold off on changing the version number until we create the release branch?