[v8] upgrade module to v8 standard go version workflow #3256
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Thank you for contributing to the CF CLI! Please read the following:
If your contribution falls under a company CLA but your membership is not public, expect delays while we confirm.
Note: Please create separate PR for every branch (main, v8 and v7) as needed.
Description of the Change
This change upgrades the module name according to the new go version workflow as described in https://go.dev/doc/modules/release-workflow
It also has a small fix in the app_summary_displayer_test.go date regex so that it supports up to 4 character time zone abbreviations
The fix is presented as a transitional one, the cli has dependency to the archived project https://github.com/cloudfoundry-incubator/cfnetworking-cli-api which doesn't use go modules and has a recursive dependency back to the cli. This makes it difficult to smoothly upgrade it in the future. The project now has a dependency of the latest vli version without modules (v7.1.0) which is used by the UAAClient to also create a legacy connection and then use it when creating the cf networking client. It's less than optimal.
The way forward is to remove the recursive dependency by either unarchiving the cfnetworking project (and removing the recursive dependency), creating a new library or adding the cf networking client directly to the cli code base. This workaround is a quick fix to move forward with standard versioning.
Why Is This PR Valuable?
At the moment the development of plugins with go modules is dependent on cli v7.1.0 (which is still not a module). This implies that plugins cannot be updated with any security and version updates that may come from newer versions.
The PR will allow plugins to be updated to the latest cli version.
Applicable Issues
#2291
How Urgent Is The Change?
It has a relative urgency, if you consider the need to update plugins as well as making this change as soon as possible for further progress of the cli
Other Relevant Parties
To my knowledge this only affects plugins (and their maintainers/developers).