Giters

unicode-org / message-format-wg

Developing a standard for localizable message strings

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

We should relax the stability policy for the tech preview release

eemeli opened this issue · comments

commented

One particularly powerful commitment that we're currently making is this part of our Stability Policy:

Updates to this specification will not introduce message syntax that, when parsed according to earlier versions of this specification, would produce syntax or data model errors.

The idea here is that you could write a tool that works with 2.0 syntax, and as long as it didn't touch the internals of any reserved syntax, that tool would also work for all future 2.1, 2.2, 2.n syntaxes because they would only ever modify the parts that we had explicitly reserved.

I'm starting to think that for next spring's tech preview release we should not make this commitment, and to allow for later releases to introduce syntax that a tech preview parser would not understand. This would allow us to leave out for now all the reserved rules, and to not tie our hands quite so tightly regarding later changes.

Doing this would allow us to, for example:

  • Leave out standalone markup placeholders from the tech preview, but add them in later.
  • Add expression attributes to the syntax after the tech preview.
  • Table discussion on literal and pattern delimiters until later.

To be clear, I'm not proposing that we necessarily do any of the above, but we could if we first relaxed the stability policy. And perhaps most significantly, we would not need to enumerate already now all the possible changes we could consider later.

I still think that the current commitment is one we ought to make, but maybe a bit later than this coming Spring?

I would also be interested in explicitly reserving the possibility to make some breaking changes to the syntax after the tech preview release. Specifically, I remain concerned about our literal and pattern delimiter choices, but I think further discussion on them would benefit greatly from wider review comments from outside our group. Is it technically possible for us to reserve the right to make such specific changes, so that we don't need to seek full consensus on delimiters before the release?

commented

(chair hat on)

I have added this to the agenda for Monday, 2023-12-18.

Specifically, I remain concerned about our literal and pattern delimiter choices, but I think further discussion on them would benefit greatly from wider review comments from outside our group. Is it technically possible for us to reserve the right to make such specific changes, so that we don't need to seek full consensus on delimiters before the release?

If we relaxed the stability policy, such a change might be possible in a future release.

In this release, the use of pipes for quoted literals is group consensus and the reasons for disallowing single/double quotes and disallowing multiple ways to write equivalent messages has been worked over fairly thoroughly. I will only entertain reopening this topic in the 2.0/LDML45 timeframe if it takes the form of a call for a vote.

commented

I'm starting to think that for next spring's tech preview release we should not make this commitment, and to allow for later releases to introduce syntax that a tech preview parser would not understand. This would allow us to leave out for now all the reserved rules, and to not tie our hands quite so tightly regarding later changes.

I'm in favor of finding ways to allow us to cut scope, so that we can ensure the best possible quality of what we ship. I'd still encourage us to design potential post-tech-preview changes in a way that limit the risks of incompatibility, but I'm OK with not making it an explicit guarantee and a goal.