-
Notifications
You must be signed in to change notification settings - Fork 263
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
Rename --async to --no-wait and deprecate it #639
Conversation
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.
@dsimansk: 0 warnings.
In response to this:
Fixes #438
Proposed Changes
- Add
--no-wait
flag with same behaviour as--async
- Mark
--async
as deprecated in documentation and display warning message when usedExample of deprecation warning:
➜ client git:(issue-438) kn service create svc-test --image gcr.io/knative-samples/helloworld-go --async DEPRECATED WARNING: flag --async is going to be removed in future release, please use --no-wait instead. Service 'svc-test' created in namespace 'default'. ➜ client git:(issue-438) kn service update svc-test --image gcr.io/knative-samples/helloworld-go --async DEPRECATED WARNING: flag --async is going to be removed in future release, please use --no-wait instead. Service 'svc-test' updated in namespace 'default'. ➜ client git:(issue-438) kn service update svc-test --image gcr.io/knative-samples/helloworld-go --no-wait Service 'svc-test' updated in namespace 'default'.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
/assign @rhuss |
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.
Wonder if we should have a time limit on DEPRECATED flags and commands? Perhaps mentioning in the docs that commands/flags marked as DEPRECATED will be removed in future after n
number of releases? I'd vote for n == 2
. Thoughts?
The following is the coverage report on the affected files.
|
Yes, I think we definitely should establish a rule. For API versioning we have Knative Release Principles and there is a rule to support On the other hand, there is also the table about deprecation, which states which feature can be removed after which time, based on the maturity level. So if we would say |
/retest |
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.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dsimansk, maximilien, rhuss The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This is needed for latter inclusion in knative.dev. Related to knative#639.
* chore: Cleaned up README This is just a start for reorganizing the client side documentation. * chore: Add option to generate frontmatter to gendocs. This is needed for latter inclusion in knative.dev. Related to #639.
Fixes #438
Proposed Changes
--no-wait
flag with same behaviour as--async
--async
as deprecated in documentation and display warning message when usedExample of deprecation warning: