Skip to content

Do not promise stability with all options #829

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.

Sign up for GitHub

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

Closed
wants to merge 1 commit into from
Closed

Do not promise stability with all options #829

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion spec/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -82,7 +82,8 @@ A reference to a _term_ looks like this.
Updates to this specification will not change
the syntactical meaning, the runtime output, or other behaviour
of valid messages written for earlier versions of this specification
that only use functions defined in this specification.
that only use functions defined in this specification
and options explicitly defined for them.
Comment on lines +85 to +86
Copy link
Member

@aphillips aphillips Jul 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recall that there is a function registry that we're creating and it's versioned. We need to incorporate stability for the function registry. While this wording is fine for the limited purpose of fixing the current text, I think we need to separate the output guarantee and function registry promised from the syntax guarantee intended here.

Copy link
Collaborator Author

@eemeli eemeli Jul 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not only intended to provide a guarantee about the syntax; the mention of "runtime output, or other behaviour" is explicitly included.

Copy link
Member

@aphillips aphillips Jul 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get it. The problem is that "the runtime output" can't be stabilized--CLDR data changes all the time! And "other behavior" is too nebulous. We also don't want to promise things like "the selection won't change" or "the formatting won't change". Much of what happens in an MF2 message is actually controlled by the locale, data, and local implementation of the functions.

I think an overhaul is probably warranted?

Suggested change
that only use functions defined in this specification
and options explicitly defined for them.
Updates to this specification will not make any well-formed or valid _message_ invalid.
Functions and options defined in this version of this specification shall not be removed. Options and option values can be added. Existing options and option values will not be removed.

Copy link
Collaborator Author

@eemeli eemeli Jul 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that an overhaul as you propose is a separate PR. I'd be happy to consider it, but it needs to be considered in the wider context of the whole stability policy.

Would you be comfortable with us adopting this smaller change first, and then reworking a greater part of the policy? I continue to prefer smaller steps that improve the spec, even if we do identify while taking them that further subsequent steps will be needed.

Copy link
Member

@aphillips aphillips Aug 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I don't think so. Is this PR obsolete in light of #834 and the changes we're making for #634/the function registry?

Updates to this specification will not remove any syntax provided in this version.
Future versions MAY add additional structure or meaning to existing syntax.

Expand Down