4 The change request and the release

4.1 Once it is approved, nobody edits it

The moment a specification reaches version x.0.0, the way it changes changes.

Change control is the name of that regime, and its definition is one line: a procedure whereby proposed modifications are put to the TSG for approval as formal change requests ^[6].

A change request itself is defined just as tightly — a formal proposal, on a standard form, to modify a specification under change control ^[7].

Before a document is under change control the same work is done by a pseudo change request, a pCR, which carries no number because there is nothing yet to number against ^[8].

Both are everywhere. Of the 1,629,581 meeting documents on record ^[9], 516,786 are change requests ^[10] and another 159,031 are pseudo change requests ^[11].

4.2 Anybody may raise one, and the number is forever

Two rules make the system open at the front and strict behind it.

The number is allocated by the 3GPP portal or by the Support Team, and every revision of every change request stays in the database §4.6.1. A change request that was refused keeps its number and its place in the record, so "we tried that in 2014 and it was turned down" is a checkable statement.

4.3 What is on the form

The cover page carries the management facts: which specification and which version it is written against, who it comes from, the reason for it and the consequences of refusing it, its category, and its effect on compatibility §4.6.2.

The category is the field people argue about, and there are five in use §4.6.2:

• A — corresponds to a change already made to an earlier release.
• B — addition or deletion of a feature.
• C — functional modification of a feature.
• D — editorial modification, with no effect on an implementation.
• F — correction of an error, an ambiguity, a botched earlier change, or a mismatch between the stages.

If the category cannot be identified when the change request is presented, it is automatically rejected §4.6.2.

Behind the cover page go the affected clauses themselves, with the proposed changes marked in the word processor's revision mode, so the group reads the change rather than a description of it §4.6.3.

4.4 The path, and the whole-or-nothing rule

A proposed change goes first to the group primarily responsible for the document. Comments from secondary groups have to have been asked for and taken into account before it goes further §4.6.4.

Once the working group agrees it, its secretary collects all agreed change requests and sends them to the parent TSG for approval §4.6.1. The Support Team collates them into change-request packs for the plenary §4.6.4.

That is why the document also says one change request should cover one technical topic. A form carrying three unrelated ideas cannot be half-approved, so all three fall together §4.6.1.

On approval, the Support Team edits the specification and issues a new version: the middle digit goes up and the last resets, so 7.2.1 becomes 7.3.0 §4.1.1. A purely editorial fix by the Support Team moves only the third digit, and the document says such changes should normally wait until the next technical change comes along §4.6.6.

4.5 What a release actually is

That second sentence is the whole idea. A release is not a date and not a marketing name: it is a set of documents that are consistent with each other, so somebody can build a working system from the set and nothing else.

Which release a version belongs to is simply the first digit of x.y.z §4.0B. The catalogue records 19 named releases ^[12] and 20,793 specification-and-release pairs ^[13] — that second number is what "one specification exists in several releases at once" looks like in the data.

The document sets out what a release has to be §4.10.3: a well-defined, stable and internally consistent set of functions, documented in a maintained and consistent stream of specifications. Releases are not annual, and are named after the major version field — Release 4, Release 5 and so on §4.10.3.3.

4.6 Corrections go backwards, features go forwards

This is the rule that generates most of the traffic.

New or changed functionality goes into the latest release that is not yet frozen, never back into a frozen one. Putting it back would break interoperability between systems already built to that release §4.10.3.2.

Essential corrections travel the other way: the same fix is made in every earlier release that is not closed §4.10.3.1. That produces mirror change requests.

The plenary approves the principal change request and its mirrors together, so the releases cannot drift apart §4.10.2.

4.7 Frozen, closed, withdrawn

Three states, and they are not the same thing.

Frozen means only essential corrections are permitted ^[14]. The document nicknames the essential-correction case a FASMO, for "Frequent And Serious MisOperation" §4.7. Alignment changes are also allowed, to bring a document into line with the agreed functionality of its own release §4.7.

Closed means no changes of any kind, not even a correction to line up with a later release ^[15], §4.8.

Withdrawn removes a specification altogether, and only after the TSG has made certain that no other 3GPP specification still points at it §4.9.

Freeze dates are set per stage in the work plan, and on freezing stage 2 of one release the TSGs should already be proposing the dates for the next §4.10.3.4. No file read for this course carries those dates, so this course gives none.

A feature that will not make the freeze date has two ways out: it drops to the next release, or the responsible group raises an exception sheet asking for one or two more meeting cycles §6.4.5.