Content for TR 21.900 Word version: 18.1.0
4.10 Release control
4.10.1 Creation of a new Release version of a specification
4.10.1.0 General
4.10.1.1 With no technical changes compared to the previous Release
4.10.1.2 When introducing technical changes
4.10.1.3 Specifications not propagated to next Release
4.10.2 Mirror Change Requests
4.10.3 Release mechanisms
4.10.3.1 Corrections to Releases
4.10.3.2 New features
4.10.3.3 Release naming
4.10.3.4 Introduction of features into Releases
4.10.3.5 Early implementation of features
...
...
4.10 Release control p. 22
4.10.1 Creation of a new Release version of a specification p. 22
4.10.1.0 General p. 22
The concept of Releases was introduced in clause 4.0B. A given specification may simultaneously exist in several versions, each corresponding to a different Release.
In principle, a Release of the specification can be identified as consisting of all those specifications with a "major" version field of a given value.
4.10.1.1 With no technical changes compared to the previous Release p. 22
A given Release consists of a set of specifications having a common "major" version field; therefore, for the set of specifications to be complete, a new specification needs to be produced even if its provisions are identical with those of the previous Release's version. The creation of such a specification shall be delayed until the latest possible moment - that is, until the TSG is on the point of declaring a given Release to be complete, having determined that no technical changes are needed in the specification compared with the previous Release.
The creation of the new version under these circumstances shall be via the responsible TSG's taking a decision to upgrade to the next Release of the specification.
This implies that all Groups need to conduct a rigorous review of all specifications for which they are responsible to determine which are to be propagated to the next Release and which are not.
4.10.1.2 When introducing technical changes p. 22
A new version of a specification, corresponding to a new Release, shall be prepared when a technical change needs to be introduced to satisfy a requirement of a feature of that new Release. This shall be accomplished by the raising of a Change Request (see clause 4.6) in the usual way, with the version number of the resulting specification indicating the new Release. The CR shall bear the identity of the new Release (rather than the starting point Release - see clause 4.6.2).
4.10.1.3 Specifications not propagated to next Release p. 22
Specifications which are not propagated from Release N-1 to Release N in one of the above two methods shall be deemed not to form part of Release N. Under these circumstances, the responsible Group shall undertake a review of all other specifications of Release N to eliminate references to the specification concerned.
4.10.2 Mirror Change Requests p. 23
When a Group produces a Change Request changing an early Release of a specification, it shall check whether the same change also needs to be made to later Releases of the specification. Changes which are corrective or clarifying in nature will generally be applicable to such other versions.
Where it is determined that several Releases are affected, an (independently numbered) Change Request shall be created for each such affected version of the specification. Such CRs are termed "mirror Change Requests". The principal CR and its related mirror CRs should be grouped together for the purpose of presentation to the TSG (unless some other grouping is more logical).
The TSG shall approve (or postpone or reject) a CR to a given Release together with the corresponding mirror CRs to later Releases. This will provide consistency between Releases.
See also subclause 4.6.2.
4.10.3 Release mechanisms p. 23
It is important that the 3GPP release structure provides a sound basis for implementations and equipment interoperation. Key principles important to ensure this are:
- A Release shall consist of a well-defined, stable and internally consistent set of functions.
- A Release shall be documented in a maintained, consistent stream of specifications.
- Essential corrections to a stable or frozen release shall be included in the applicable Release.
- New or changed functionality shall be included in a new (rather than retrospectively in an old) Release.
4.10.3.1 Corrections to Releases p. 23
Each release should be consistent and implementable to ensure interworking. This implies that essential corrections become normative parts of the Release as soon as possible. If essential changes to "old" functionality are made to a new release, similar corresponding changes shall be made to correct the same error in the specifications pertaining to all previous, non-closed, Releases. This is illustrated in Figure A.
4.10.3.2 New features p. 24
New functionality shall be included in the latest, non-frozen, Release. New functionality shall not be included in previous, frozen, Releases. To do so would cause incompatibility amongst instantiations of those Releases. This is illustrated in Figure A.
4.10.3.3 Release naming p. 24
GSM phase 2+ specifications were grouped into annual Releases from 1996 to 1999. The first 3rd generation specifications were grouped into an initial Release 1999.
Subsequent Releases are not necessarily annual, and shall be referred to as Release 4, Release 5, etc., according to the major field of the version number (see Table 4 and clause 4.3).
4.10.3.4 Introduction of features into Releases p. 24
Development of the 3GPP system specifications shall be controlled by means of a work plan covering the inclusion of new features (functionality). Target dates for completion of Work Items (see clause 6) shall be estimated by the responsible Groups. Milestones may be defined to monitor the progress of Work Items. Based on the estimated completion of the desired features, a target date for freezing of the specifications pertaining to the next Release can - and shall - be calculated. Feature development should be based around approximately annual Releases.
Thus the work plan shall indicate (a) the estimated freeze date of forthcoming Releases and (b) the functional content of each such Release. The work plan shall show all projected work, regardless of Release; this will ease long term planning and the packaging of features into Releases. Completed Work Items shall be removed from the plan once the Release of which they form a part has been frozen.
3GPP technical coordination should set target dates for the freezing of each individual stage (cf. clause 4.1) on all currently worked-upon Releases (i.e. non-frozen).. On freezing stage 2 of Release x, TSGs should propose a target freeze date for stages 1, 2 and 3 of Release x+1. It is possible that features of exceptional complexity may span more than one Release (eg new core network architecture, new radio interface).
The freezing date for a particular stage of a Release should insofar as is possible be adhered to, even if, due to delays, it is not possible to include all the features originally intended. Features which cannot be completed in time should be held over to the next Release. It will normally be the case that test specifications and O&M specifications will not necessarily be completed until some time after the base specifications; this shall not impede the freezing of the Release as a whole. However, if it becomes evident that, due to delays in a number of important features, a new Release would contain little new functionality, it may be preferable to delay the freezing of the stage of a Release to allow more of the originally intended features to be included.
The project plan shall clearly show the progress of each Work Item. When all component Work Items of a feature have been completed, the TSG shall declare the feature to be frozen. The only further development permitted from that point onwards shall be:
- the essential correction of errors;
- the completion of the test and O&M specifications; and
- unavoidable adjustments required to cater for interworking with other features in the same Release.
4.10.3.5 Early implementation of features p. 25
3GPP may identify certain features as being suitable for "early implementation". The selection of "early implementation" features shall be performed at the TSG level.
Additional documentation is provided for early implementation features (see clause 6.4.4).
All documentation for early implementation features is contained in the Release where the feature is introduced. The status or specification of older Releases shall not be changed by the introduction of early implementation features.
