3GPP 21.900 v20.0.0 — the document's own text
4.1.1 General
Taught in 4. The life of a 3GPP document, from blank page to published version (How standards actually get made, in depth), 3. From an idea to an approved version (How standards actually get made, overview), 4. The change request and the release (How standards actually get made, overview), 3. One idea, from proposal to published text (How standards actually get made, quick start).
A new specification shall be created in a Group. At creation, a rapporteur shall be appointed. The rapporteur shall produce an initial draft, version 0.0.0, and subsequent revised versions (version 0.1.0, possibly 0.1.1, 0.1.2 and so on, then version 0.2.0 etc.). Details of the role of the rapporteur are described in clause 4.1.2.
The rules for drafting specifications, and the software tools to be used are listed in 3GPP TR 21.801 [1].
Versions 0.1.0, 0.2.0, 0.3.0 etc. should be presented to the responsible Group. Versions 0.i.1, 0.i.2 etc. may be internal to the drafting group.
Further drafts may be produced, with appropriate increments in the "technical" / "editorial" fields of the version number. Every new draft with an incremented "technical" version field shall be presented to the responsible Group. Although two or more Groups may have an interest in contributing to the development of a specification, ultimate responsibility vests in a single (responsible) Group. The responsible Group shall ensure that all other Groups which might have an interest are given the opportunity to participate in the drafting. The objectives intended to be provided or decided by a working group with secondary responsibility shall be made clear in a corresponding Work Item Description document, identifying additional rapporteurs from such secondary group(s) if necessary.
The Support Team is responsible for allocating specification numbers. As soon as title, scope and some other information on the specification is stable, the Support Team shall assign a specification number according to the provisions of clause 4.0 and shall enter the specification into the Status List of Specifications (see clause 7). The TSG Sub-Group responsible for the specification shall inform its parent TSG that such a new specification is under construction.
When a specification is sufficiently stable (see table 3), it shall be converted to version 1.0.0 (with no technical changes with respect to the previous version 0.y.z) by the Support Team, and presented to the TSG for information. Further drafts bearing version numbers 1.y.z may be produced until the specification is sufficiently stable to be approved by the TSG. At this stage, and until formal approval by the TSG, the specification is, unless it belongs directly to a TSG, under the control of the responsible TSG Sub-Group. The modalities governing the introduction of changes shall be decided on a case by case basis by the WG concerned.
Once the responsible Group considers that the draft is sufficiently stable (see table 3) that it is desirable to place it under change control, the latest version 1.y.z shall be converted to version 2.0.0 (with no technical changes with respect to the previous version 1.y.z) by the Support Team and presented for approval at the TSG.
If the TSG does not approve the draft, further drafts version 2.y.z may be produced by the responsible Group.
If the TSG does approve the draft, the approved version (with no technical changes) shall be converted to version x.0.0 where "x" corresponds to the Release identity given in table 4.
NOTE: It is thus quite normal that a 3GPP specification approved for, say, Release 4, jumps directly from version 2.0.0 to version 4.0.0; there is no Release 1999 document, therefore no version 3.y.z.
The specification shall now be under TSG change control. Further changes shall be made by means of formal Change Requests, to be approved by the TSG. On approval of a CR, the middle number shall be incremented and the right-most number reset to 0 (e.g., from 7.2.1 to 7.3.0).