-
Notifications
You must be signed in to change notification settings - Fork 14
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
Updated draft payload spec to stable #149
base: master
Are you sure you want to change the base?
Conversation
|
||
Type type = 3; | ||
|
||
enum Type { |
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.
What happened to all of these?
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.
Hmm, that is a very good question, I don't know. They are present in stable/6-payload
, I'll check the commits on draft/6-payload
and see what happened.
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.
Generally I think the workflow raw -> draft-> stable is a bit cumbersome, if multiple people are editing the same files, as those edits will be separate and merging changes is difficult.
We either find a suitable git workflow or simplify, at this stage imo we can get away with a single spec file and mark the relevant sections as raw/draft/stable, to avoid these kind of issues, but don't feel strongly about it.
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 agree with you, it would be a much simpler process to have a single spec file and have dedicated raw/draft/stable sections.
How do you imagine the approach:
Approach A
# Stable
## A Stable Section
## Another Stable Section
## Yet another Stable Section
---
# Draft
## A Draft Section
## Another Draft Section
## Yet another Draft Section
---
# Raw
## A Raw Section
## Another Raw Section
## Yet another Raw Section
or
Approach B
## A Section About A Thing [stable]
## A Section About Another Thing [draft]
## A Section About Yet Another Thing [stable]
## A Section Discussing Something [stable]
## A Section On The Topic of A Thing [raw]
Benefits of Approach A, all sections of the same stability are together and not mixed.
Benefits of Approach B less git diffs caused by moving text within a document. Only the spec state tag is changed.
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 favor maybe Approach B, but we can try either and see which one is more comfortable, or keep things as they are, I don't have a strong opinion.
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.
FWIW in Vac specs we have something similar to approach B.
There is a general state of the spec as a whole (raw/draft/stable), then specific (optional) sections might be marked as raw/draft etc.
This makes it clear what the state of the spec as a whole is, and points to behaviours that are still experimental.
What's the state of this PR? |
All of the differences in the current draft are now included in the shipped version of the status app.