Establish explicit test plan life cycle in working mode

[mcking65]

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.

[mcking65]

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.