Content for  TR 21.900  Word version:  18.2.0

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.

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.

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).

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.

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.

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.

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).

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.

See clause 6 for further information on Work Items.

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.