The Kernel Standardization Process

6 Appendix A: The Kernel Standardization Process

[This Appendix is not part of the Standard.]

6.1 Why plan a process?

The Eiffel Kernel Library cannot be specified for eternity. Ideas willcome up for new classes and features; ways will be found to do thingsbetter. The evolution process must be fast enough to enable Eiffel usersto benefit from this flow of ideas and avoid technical obsolescence, but orderly enough to protect their existing investments and modes of operation.

6.2 Cycle time

A revision every ten to fifteen years, as has occurred for programming language standards (Fortran, C and Ada are examples) is not appropriate for the Eiffel Kernel Library. It would foster complacency most of the time, and major upheavals when a revision is finally brought into effect. A yearly process, similar to the upgrading of wines, car models and stable software products, provides the right pace of change.

6.3 Vintages

Each revision of this Standard describes a vintage of theEiffel Library Kernel Standard. The present version is vintage 1995.

6.4 Yearly schedule

The following deadlines apply to year year:

6.4.1: 1 January: Vintage year takes effect.
6.4.2: 1 April: first permitted date for starting discussions on Vintage year+1 in NICE's Library Committee. (1 January to 31 March is acooling-off period.)
6.4.3: 1 May: first permitted date for submitting formal proposals to the Library Committee for Vintage year + 1.
6.4.4: 1 July: last permitted date for submitting initial proposals for Vintage year + 1.
6.4.5: 1 September: last permitted date for submitting final proposals (which may result from merging of several proposals) for Vintage year + 1.
6.4.6: 1 October: last date by which the Committee may have defined Vintage year +1.

This schedule is applicable starting with vintage 96. For the present vintage (95), the first, the date of applicability is 1 July 1995.

6.5 Intermediate corrections

During the time when a vintage is in effect, minor corrections may prove necessary, due for example to typographical errors in the current version of this Standard or to inconsistencies discovered by users or implementors of Eiffel. In such a case the chairman of the Library Committee of NICE may, at his discretion, submit a motion covering one or more revisions. To be approved, such motions shall require a unanimous vote of the Library Committee, with the possible exception of any member who has notified the chairman of an absence of more than one month. If approved, such a revision shall receive a revision level and shall give rise to a modified Kernel Library Standard, identified as "Vintage year Level revision_level". The modifications shall be integrated into the following year's vintage.

6.6 Eiffel Kernel Supplier requirements

Any provider of an Eiffel environment must make the following information available to any NICE member:

6.7: Vintage and revision level currently supported.
6.8: Any features not supported. (It is not permitted to have a non-supported class.)
6.9: List of classes needed by kernel classes, but not in the kernel, hereafter referred to as para-kernel classes.
6.10: Full inheritance hierarchy of kernel and para-kernel classes.
6.11: List of names of features (immediate or inherited) that appear in the provider's kernel classes but not in this Standard.