Two rules in this plan meet here and nothing has been written about what happens
when they do.
A record is permanent. It is not deleted, and an answer already on the default
branch may be added to and not rewritten. That is the rule this board's central
claim rests on.
The format grows. Two issues in this plan add a field to it after it is fixed,
and the compatibility position says the record format may change and that a change
invalidating existing records will not be made silently. Saying it will not be
silent is not the same as saying what it does.
The collision is concrete and it arrives the first time a field is required rather
than optional. The field lands, every record written before that day lacks it, the
checker refuses all of them, and the default branch is red with two repairs
available: edit records that are supposed to be permanent, or weaken the check
that just landed. Both destroy something, and the one taken under a red board will
be whichever is quicker.
Decide it now, while the answer costs nothing, and record it with the options.
New fields are optional and only ever refuse when present. This is what the plan
has been assuming without saying so, since both issues that add a field refuse a
contradiction or an empty declaration rather than an absence. The cost is that the
format can never require anything again, so a field that matters is a field an
author may simply omit, and the checker cannot tell an omission from a decision.
A version in the header, with the checker holding the rules for each version it
has ever known. The cost is a field in every record forever, most of them carrying
the same number, and a checker that grows a branch per version and never loses
one.
A required field that applies from a date, refusing records whose question date is
after it. The cost is that the checker carries a date, that a reader has to know
the date to understand why two records in the same directory are held to different
rules, and that the date is trusted from the record it is judging.
Whichever is taken, the record has to say what happens to the records already on
the default branch on the day of the change, in those words, because that is the
sentence somebody will be looking for while the board is red.
The record is numbered ahead of the two that supersede the format, because both of
them add a field and both therefore answer to this decision rather than the other
way round.
Done when docs/decisions/0013-how-the-record-format-changes.md exists on the
default branch, states which option is taken and why, names the rejected options
with their costs, states what happens to records already on the default branch
when the format changes, states that a permanent record is not edited to satisfy a
new rule, and the compatibility position points at that record instead of
restating it.
Two rules in this plan meet here and nothing has been written about what happens
when they do.
A record is permanent. It is not deleted, and an answer already on the default
branch may be added to and not rewritten. That is the rule this board's central
claim rests on.
The format grows. Two issues in this plan add a field to it after it is fixed,
and the compatibility position says the record format may change and that a change
invalidating existing records will not be made silently. Saying it will not be
silent is not the same as saying what it does.
The collision is concrete and it arrives the first time a field is required rather
than optional. The field lands, every record written before that day lacks it, the
checker refuses all of them, and the default branch is red with two repairs
available: edit records that are supposed to be permanent, or weaken the check
that just landed. Both destroy something, and the one taken under a red board will
be whichever is quicker.
Decide it now, while the answer costs nothing, and record it with the options.
New fields are optional and only ever refuse when present. This is what the plan
has been assuming without saying so, since both issues that add a field refuse a
contradiction or an empty declaration rather than an absence. The cost is that the
format can never require anything again, so a field that matters is a field an
author may simply omit, and the checker cannot tell an omission from a decision.
A version in the header, with the checker holding the rules for each version it
has ever known. The cost is a field in every record forever, most of them carrying
the same number, and a checker that grows a branch per version and never loses
one.
A required field that applies from a date, refusing records whose question date is
after it. The cost is that the checker carries a date, that a reader has to know
the date to understand why two records in the same directory are held to different
rules, and that the date is trusted from the record it is judging.
Whichever is taken, the record has to say what happens to the records already on
the default branch on the day of the change, in those words, because that is the
sentence somebody will be looking for while the board is red.
The record is numbered ahead of the two that supersede the format, because both of
them add a field and both therefore answer to this decision rather than the other
way round.
Done when
docs/decisions/0013-how-the-record-format-changes.mdexists on thedefault branch, states which option is taken and why, names the rejected options
with their costs, states what happens to records already on the default branch
when the format changes, states that a permanent record is not edited to satisfy a
new rule, and the compatibility position points at that record instead of
restating it.