On 2026-03-13 11:09, Alistair Francis wrote: > The problem here is that there is no version control. If we merge this > series and the PR changes then suddenly we are out of sync there is no > way to track which version of the draft spec we support. > > We need clear versions, like we previously have. For example version > 0.7 and then 0.8. Draft versions are ok, but we need a stable target > to develop against. > > > > > PR #2743 is currently open, meaning ratification is pending but not > > yet complete. Under the new workflow, merge into main of > > riscv-isa-manual is the signal that ratification is finalized. If you > > prefer to wait until that merge happens before applying this patchset, > > I completely understand. Alternatively, if you are comfortable > > accepting it as ratification-pending, I am happy to address any > > remaining technical comments. > > In this case we will have to wait as there is no stable version of the > spec to point to. > > Alistair >
Hi Alistair, Thank you for your feedback on the version control and stability of the Zvfbfa specification. I understand your concern about developing against a moving target. To address the lack of a stable target as you mentioned, I’d like to help bridge this gap. Since this patchset was prepared based on the Zvfbfa version v0.1 and this version has passed the ARC review, I propose we coordinate with the Zvfbfa isa designer to check the specific tag/commit ID of the Zvfbfa v0.1. If we could create a tag or release for v0.1 (e.g., v0.1/v0.1-draft) within the Zvfbfa repository that explicitly marks the current state of the Zvfbfa spec, would that provide the necessary versioning baseline for you to accept this patchset? My goal is to ensure QEMU supports a traceable version of the draft spec while respecting the current RVIA development process for this ISA implementation patchset and the followings in the future. rnax
