w3c
Establish explicit test plan life cycle in working mode
The current version of the working mode does not explicitly define the life cycle path of a version of a test plan. It implies that a plan moves from R&D to Recommended in a straight line but does not explicitly address what happens to a version of a test plan when it is made obsolete by a newer version.
This issue is complete when the working mode and glossary clearly describe how a test plan is versioned and what the full life cycle of a specific version of a test plan is.
Defining test plan version
Recommendation: Define test plan version in the glossary.
Definition proposal:
The version of a test plan is identified by a commit date-time stamp in its test source repository. Each repository that serves as a source of tests has a branch that serves as a test publication branch. A new version of a test plan is created when a commit to the test publication branch changes one of the plan's source files. For example, a new version of an APG pattern test plan is created when a commit to the master branch of the w3c/aria-at repository changes the source of the plan.
Proposal for test plan version life cycle
- A given test plan may have only one version in the draft, candidate, or recommended phases of the working mode:
- Advancing a version of a plan into the draft phase replaces the current draft version if one exists.
- Advancing a version of a plan into the candidate phase replaces the current candidate version if one exists.
- Advancing a version of a plan into the recommended phase replaces the current recommended version if one exists.
- When an older version of a plan is replaced by a newer version, the older version is sunset.
Per discussion in aria-at-app issue 632, the term "deprecated" is preferable to "sunset". It more accurately represents the state of the version of a plan. That is, when V2 replaces V1 of a plan, it is because V1 is no longer considered current , and V1 should no longer be used.