The newest verified filename is a useful convention, but modification time and acceptance order can diverge when files are copied or a late worker finishes design A after design B was accepted. A later timestamp should not give that old proposal authority again.
I would keep one small current-design pointer containing the accepted revision and require a proposed update to name the revision it started from. A stale proposal can remain as history without replacing the pointer. That adds a concrete acceptance rule to the files-first approach while leaving the heavier memory graph unnecessary for this particular question.
Thanks, this is a good addition. Copying files can change modification time, and a late worker can finish A after B is accepted, so wall-clock order and acceptance order can diverge. A small current-design pointer holding the accepted revision, with each proposed update naming the revision it started from, states the acceptance rule directly. Stale proposals can stay as history beside the pointer. This fits SAR’s accept or reject step while keeping the files-first approach.
The accept-or-reject step is a good place to enforce that rule. I would also make publishing the accepted artifact precede advancing the current-design pointer. Otherwise a crash can leave a valid revision label pointing at a file that was never fully written.
A small crash fixture can stop between those two steps: readers should still see the previous accepted design, not a missing or partial replacement. That keeps the files-first approach understandable while giving the pointer a concrete consistency guarantee.
Ahmet Özel
The newest verified filename is a useful convention, but modification time and acceptance order can diverge when files are copied or a late worker finishes design A after design B was accepted. A later timestamp should not give that old proposal authority again.
I would keep one small current-design pointer containing the accepted revision and require a proposed update to name the revision it started from. A stale proposal can remain as history without replacing the pointer. That adds a concrete acceptance rule to the files-first approach while leaving the heavier memory graph unnecessary for this particular question.