Proposal: Schedule `results.tests[].id` for Removement Before CTRF Release 1.0.0
还没有人认领这个 Issue。
评估
- 难度
- 3/5
- 预计耗时
- 半天
- 新手友好度
- 32/100
- Issue 类型
- 文档
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- json
调研方向
The change belongs in the spec text for section 9.1 (id) of the CTRF specification, which should point to section 9.2 (testId). Read the deprecation notice and the sentence about consumers treating id as legacy, then settle that sentence with the maintainers before editing. Done means the agreed wording is merged and the 1.0.0 removal date is stated consistently.
由索引模型根据 Issue 内容生成。
描述
I propose to document the removement of results.tests[].id with the release of CTRF version 1.0.0 latest.
The goal is to avoid starting with a legacy in the first CTRF version.
Below is my preliminary draft proposal for updating the documentation to apply some pressure and make it clear that id will be removed by version 1.0.0 at the latest.
9.1. id
Legacy.
idis deprecated and scheduled for removement. Producers SHALL use/switch totestId(Section 9.2).Description:
A unique, stable identifier for the test case.Requirements:
idis OPTIONAL.
If present, it MUST be a valid UUID as defined in [RFC4122].Deprecation Notice:
For producersidis scheduled for removement with CTRF version 1.0.0.
New producer implementations MUST usetestIdinstead ofidfrom beginning.
Existing producers implementations SHALL switch fromidtotestIdbefore CTRF version 1.0.0.
Consumers may supportidbeyond CTRF version 1.0.0 as follows for CTRF versions < 1.0.0:
When bothidandtestIdare present, consumers SHALL usetestId.
I do not understand the intention behind:
Consumers SHOULD treat
idas legacy unless a producer documents stronger semantics.
So I felt free to just remove this sentence :-).
P.S.: Of course, the wording suggested above is a pre-1.0 wording.
For version 1.0.0 it will then need to be reworded accordingly.
What do you think about this?
- 主要语言
- 没有语言数据
- 星标
- 98
- 派生
- 4
- 平均合并
- 1 小时 21 分钟
- 30 天内合并 PR
- 1
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
ctrf-io/ctrf 的其他 Issue
-
难度 1/5 1 小时以内 新手友好度 76/100
-
难度 4/5 1-2 天 新手友好度 48/100
-
难度 5/5 一周以上 新手友好度 35/100
-
难度 5/5 一周以上 新手友好度 30/100
-
难度 5/5 一周以上 新手友好度 35/100
相似的 Issue
-
sync-en
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
sync-en
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 4 天内回复
-
area:connector bug
难度 1/5 1 小时以内 新手友好度 82/100
维护者通常 1 天内回复
-
environment: OPENCODE_API_KEY is described as a Console service account key, but a Go subscription key works可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
tester-army/e2e#1015 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 90/100
chroma-core/chroma#7879 ·
维护者通常 1 天内回复