Proposal: Schedule `results.tests[].id` for Removement Before CTRF Release 1.0.0
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- Medio día
- Aptitud para principiantes
- 32/100
- Tipo de issue
- Documentación
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- json
- Área
- documentation
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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?
- Lenguaje dominante
- Sin datos de lenguaje
- Estrellas
- 98
- Forks
- 4
- Merge medio
- 1 h 21 min
- PR fusionados (30 d)
- 1
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de ctrf-io/ctrf
-
Also Mention UUID version 8Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 76/100
-
Dificultad 4/5 1-2 días Aptitud para principiantes 48/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
Todos los issues de ctrf-io/ctrf
Issues similares
-
How do I build the project?Abierto
Dificultad 1/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
AR-js-org/arjs-plugin-artoolkit#70 ·
Los mantenedores suelen responder en 1 día
-
documentation good first issue help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
-
docs good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
CGSeb/lessonfolk#201 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
EasyTier/EasyTier#2672 · 1 comentario ·
Los mantenedores suelen responder en 1 día