-
Notifications
You must be signed in to change notification settings - Fork 49
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
Add @Feature annotation with categories #566
Conversation
|
||
/** | ||
* Enum of allowed stages. | ||
*/ |
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.
Is there a doc that pinpoints what each of these stages means to the UDMI project? For example ALPHA vs PREVIEW
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.
Also occurs to me, should "REQUIRED" be renamed "RELEASE"?
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.
I'd like to scope this PR at the mechanism for specifying the properties, but not the properties themselves (leave changing that to a separate PR). Once this PR is in place, it's easy to add/change the values themselves, and/or the properties associated with any given feature.
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.
If you change the enum to just one placeholder value I'm good with that. Then we can go back and edit the real values in place.
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.
How about two -- I'd like to keep default and non-default since the code/output is different in those two cases! Updated, PTAL.
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.
Ok...as long as we can change REQUIRED to a different label if needed lgtm
validator/src/main/java/com/google/daq/mqtt/sequencer/sequences/BlobsetSequences.java
Outdated
Show resolved
Hide resolved
Eventually yes, but I'd like to keep that as a separate activity. After
this PR, I want to have some generated NAMED_CONSTANTS for the categories
to prevent string typos, etc... Similar to the error categories! All just
staging steps to the eventual goal...
…On Thu, Jan 26, 2023 at 1:35 PM John R ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In
validator/src/main/java/com/google/daq/mqtt/sequencer/sequences/BlobsetSequences.java
<#566 (comment)>:
> @@ -198,7 +198,7 @@ public void endpoint_connection_success_alternate() {
@test
@description("Restart and connect to same endpoint and expect it returns.")
- @FeatureStage(PREVIEW)
+ @feature(stage = PREVIEW)
I meant should we fill in category values that Nour is generating. But we
can revisit this when we settle the enums, too.
—
Reply to this email directly, view it on GitHub
<#566 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIEPD5T65JYGOLVYTJQBWTWULU3RANCNFSM6AAAAAAUGKQZQQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
||
/** | ||
* Enum of allowed stages. | ||
*/ |
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.
Ok...as long as we can change REQUIRED to a different label if needed lgtm
No description provided.