Skip to content
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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Samyoul
Copy link
Member

@Samyoul Samyoul commented Sep 8, 2020

All of the differences in the current draft are now included in the shipped version of the status app.


Type type = 3;

enum Type {
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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.

@oskarth
Copy link
Contributor

oskarth commented Mar 25, 2021

What's the state of this PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants