The Release Process

From wiki.eclass.eu
Jump to: navigation, search

The eCl@ss maintenance process is based on ISO requirements and similar to the maintenance process of other standards as e.g. the DIN property server. To facilitate the development of the standard for every interested user, the eCl@ss ContentDevelopmentPlatform (formerly knows as ServicePortal) was developed as an online platform to give every user the possibility to submit change requests for the standard. The eCl@ss association distinguishes three different types of releases that will be described in the following section.

Contents

[edit] MajorRelease

An eCl@ss MajorRelease is a release type that includes all possible modifications of existing structural elements (including structural modifications) and the addition of new structural elements, as well as modifications of the relations between existing structural elements. eCl@ss MajorReleases:

  • include every kind of change including structural changes (including changes of the class hierarchy, changes of existing relations between structural elements, the withdrawal or removal of certain structural elements, the moving, joining and splitting of classes etc.). For an overview please have a look at the list of valid change requests per release.
  • are not downwards-compatible to previous releases due to possible structural changes
  • cannot be integrated into a system as an upgrade of the previous version automatically. This process is supported though not fully automated by available transaction update files and release update files. A manual re-mapping process of one’s data might still be necessary
  • are published every 2 or 4 years (see Release Roadmap below)

[edit] MinorRelease

An eCl@ss MinorRelease is a release type that includes the modification of certain attributes of existing structural elements (e.g. textual changes) and the addition of new structural elements, as well as new relations between new and/or existing structural elements. eCl@ss MinorReleases:

  • include additions (possible on all hierarchical levels), the removal of erroneous keywords and suggested property values and, if necessary, the correction of certain attributes of existing structural elements (e.g. clerical errors). For an overview please have a look at the list of valid change requests per release.
  • are downwards-compatible within the same MajorRelease number (e.g. all 6.x releases with each other, all 7.x releases with each other etc.)
  • can automatically be integrated into a system as an upgrade of the previous version as only version changes of existing structural elements and additions of new structural elements are made
  • are planned to be published once a year (see Release Roadmap below)

[edit] Service Pack

An eCl@ss ServicePack is a release type that corrects a previously released language version by exclusively allowing textual changes in a specific language variant of the eCl@ss standard. eCl@ss ServicePacks

  • exclusively comprise the removal of potential errors that do not affect the content, therefore generally the correction of clerical errors and translations. For an overview please have a look at the list of valid change requests per release.
  • are designed for short-term use to correct major errors in a specific language variant and are therefore language-specific
  • are not integrated into the release roadmap and can therefore be published on demand if needed for a specific language version
  • are downwards and upwards-compatible to the previous MinorRelease as well as to every MinorRelease within the same MajorRelease number (e.g. all 6.x releases with each other, all 7.x releases with each other etc.) as they comprise only textual changes
  • can automatically be integrated into a system as an upgrade of the previous version as only revision changes of existing structural elements are made
  • are coded with the help of a MajorRelease Number, a MinorRelease Number, a ServicePack Number and a language and country code (n.n.X, e.g. 6.2.1 ZH_cn – the ServicePack 1 of the eCl@ss MinorRelease 6.2 in Chinese simple). NOTE: Before release 6.0.1 ServicePacks included additions as well (new classes at levels 2 – 4, new keywords, properties and values) and were very similar to a Minor Release (see above).

[edit] Release Numbers and Versioning

The eCl@ss data model defines the format of release numbers, the versioning of changes and additions as well as the consequences for the release number. The release number consists of a "Major Release Number" (x.0) and a "Minor Release Number" (n.x). A ServicePack additionally comprises a "ServicePack Number" (n.n.x). These numbers are separated by the punctuation mark dot (e.g. ServicePack 6.2.1 ZH_cn). Release Numbers do not comprise a leading zero (e.g. 11.2.1 instead of 11.01.02).


Release Number Type Release Number Format Description Depends on language version?
Major Release Number CHAR(3) The raising of the „Major Release Number“ shows that changes have occurred that are not compatible to the last release. The publication of a Major Release can result in the fact that the assignment of existing data to the new eCl@s release has to be checked and corrected. The „Major Release Number“ is mandatory for every release and is automatically created by the eCl@ss ContentDevelopmentPlatform. no


Minor Release Number CHAR(3) As long as only the „Minor Release Number“ is changed, existing data can still be used without changes, i.e. changes are upward compatible. The „Minor Release Number“ is raised when a new release is published that only consists of new structural elements or editorial changes. The „Minor Release Number“ is mandatory for every release and is automatically created by the eCl@ss ContentDevelopmentPlatform. In case the „Major Release Number“ is raised the „Minor Release Number“ will automatically be set to „0“. no
Service Pack Number CHAR(3) The Service Pack Number is raised with the publication of a new language version. The change of the "Service Pack Number" is not bound to changes of the content, but exclusively to editorial changes that also include translations. The „Service Pack Number“ is optional for a release and will only be assigned with the publication of a new or changed language variant and is automatically created by the eCl@ss ContentDevelopmentPlatform. In case the „Minor Release Number“ is changed the „Service Pack Number“ will automatically be set to „0“.

NOTE 1: As translations are never delivered within the maintenance process of a new eCl@ss Minor or Major Release, a new or enhanced translation will never be available at the point of time of releasing a Minor or Major release. Therefore, a translation will always be a ServicePack and carry a ServicePack Number. EXAMPLE: Minor Release 7.1 is published and all existing language versions are already updated to 7.1 in the data base. Now, an improved 7.1 French is delivered and processed in the data base. The result will be a 7.1.1 French. In case, this version will be changed again, the result will be published as 7.1.2 French.

NOTE 2: New or edited language variants are developped on demand and are therefore not included in the release roadmap.

yes


Figure 1: Example of an eCl@ss ReleaseNumber

Release number.jpg


The eCl@ss data model distinguishes between version changes and revision changes. Both are not visible until the publication of the following release. Version changes (e.g. the modification of the unit of a property) usually have the consequence that the users have to migrate their data when updating to a later version. This can be done automatically. In case of a version change the MinorRelease Number changes. Revisions like orthographical corrections of a text attribute do not necessarily result in the necessity to update to a new version, if a user communicates with systems that still use the same MajorRelease Number. Exclusive revision changes can be published in a ServicePack. The ServicePack Number is increased when publishing a new language variant. The increase does not imply changes of the content. If a version number is increased, the revision number is automatically set to one (“1”). If the MajorRelease Number is increased, the MinorRelease (and ServicePack) Number is automatically set to zero (“0”). If the MinorRelease Number is increased, the ServicePack Number is automatically set to zero (“0”). Version, revision and release numbers can only be increased once at the same time, even if more than one change were made on the same structural element (e.g. if both the name, the definition and the unit of a property AAA123-001 in release 7.1 were changed, its new version in release 7.2 will be AAA123-002). This also counts for possible inherited version changes in the structure.


The following dates are distinguished in eCl@ss:

Type of date Description To be found ...
VersionDate Last change date of a single structural element in the dictionary as attribute for each single structural element
ReleaseDate Date of release of the whole content of a version (e.g. 8.0 incl. SE, relations), i.e. the date the release was processed in the database in the dictionary (XML), CSV: will be added starting in 8.1
ExportDate The date the export file was created XML: dictionary header and date of file. CSV: date of file
PublicationDate The date the product was made available in the eCl@ss DownloadPortal nowhere

[edit] Change Requests (CR)

A change request (CR) is a proposal by an eCl@ss user (=requestor) to change a part of the content of the eCl@ss classification system. It can be a correction or even a deletion of something that is identified by the requestor as wrong or an enhancement of something that is still missing. Generally, the eCl@ss classification system will never be finished as changes will always be necessary as long as markets are evolving. The number of change requests processed within a release varies according to the temporary requirements of the industry. The biggest release in regard to the number of submitted change requests was eCl@ss 7.0 where more than 260.000 CR were processed. Different kinds of CR are valid in different kinds of releases, see above or have a look at the list of valid change requests per release.

All eCl@ss Change Requests have to concur to the guidelines and rules which is listed here.

[edit] ContentDevelopmentPlatform

Any interested person can submit change requests to the eCl@ss organization with the help of the online portal eCl@ss ContentDevelopmentPlatform (formerly known as eCl@ss ServicePortal).

[edit] Bulk requests

Major changes of the eCl@ss standard done by the eCl@ss expert groups can also be submitted as bulk requests with the help of MS EXCEL® import spreadsheets. As a huge amount of changes is usually prepared in a similar form by the expert groups themselves and a lot of experts have a look on it before even submitting the change requests (CR), eCl@ss provides a normalized import spreadsheet to make an import of change requests easier for expert groups. The import spreadsheet only replaces the manual change request creation in the ContentDevelopmentPlatform. Any included change will be imported as a CR.

The normalized MS EXCEL® import spreadsheet that is used for the import of bulk requests is available at the eCl@ss head office. It is mostly spread for internal use by the eCl@ss expert groups and larger projects like e.g. brand new segments.

[edit] Release Process

The eCl@ss association is organised in various bodies. The most important ones for the maintenance process are described in the following section. The eCl@ss maintenance process is described in the following figure, followed by the description of the involved user roles:

Figure 2: The eCl@ss maintenance process

Release process old 20110707.jpg


[edit] Requestor

Every interested person or organisation can take part in the development of the eCl@ss classification system. The proposal of change requests (CR) is open to everybody with the help of the online development and maintenance platform eCl@ss ContentDevelopmentPlatform. In the case of a more complex and detailed contribution, a requestor is advised to contribute to the work of an eCl@ss expert group. Every requestor has to fulfil the requirements and preconditions to create a change request. Detailed descriptions are to be found in the relevant section of. Otherwise a change request cannot be accepted by the eCl@ss association. To be able to propose change requests, a requestor simply has to register in the eCl@ss ContentDevelopmentPlatform. The registration is free of charge.


[edit] Center for Release Management

The Center for Release Management (CRM) is the organisation unit that coordinates the whole maintenance process. Among its key tasks is the release and change management of the eCl@ss classification system and a first formal check of submitted change requests (CR), e.g. if all mandatory information is included. The eCl@ss CRM forwards CR to the responsible eCl@ss expert groups and the eCl@ss Center for Quality Control (CQC). In the eCl@ss ContentDevelopmentPlatform, the office is the first of three bodies that have a role to edit the CR submitted by the requestors. It is in their responsibility to arrange related CR in workpackages and assign these to the expert groups and/or the eCl@ss Center for Quality Control. After the final decision by the CQC, CRM sets all CR for the upcoming release as released for beta version.

[edit] Expert Group

eCl@ss distinguishes two types of expert groups (EG):

  • content EG, taking care of the maintenance and further development of the content of the eCl@ss standard, i.e. the classification and description of product groups and services
  • cross-section EG, taking care of specific aspects of the maintenance and administration issues of the standard, like e.g. the technical requirements of the data model, data base etc.

The first group are those EG that will verify and edit the submitted CR.


[edit] Tasks and responsibilities of content expert groups

1. Each content EG creates CR for their dedicated area of interest (e.g. a segment) in final-decision-maturity.

2. External CR concerning their dedicated area of interest are forwarded by the eCl@ss office to the relevant content EG. The EG has to take into account these CR and consolidate them with their own work. The evaluation of external CR has to be documented in order to give feedback to the requestors.

3. CR in final-decision-maturity have to fulfill the following requirements:

3.1 All mandatory fields are filled in English (if possible, also in German and other languages)

3.2 They meet all formal requirements (ContentDevelopmentPlatform, Import Template)

3.3 They meet the guidelines on spelling, syntax, field formats, units, definitions etc.

3.4 The CR is in conformity to the data model

3.5 A CR by an eCl@ss EG has to be delivered with a decision memorandum by the EG

3.6 In case a CR was submitted for a MinorRelease its content has to be checked if it contains only compatible changes

4. The following aspects have to be considered when editing CR:

  • The class hierachy must represent the market view (of e.g. a procurement market)
  • The existing structure of the content must be considered and breaks largely be avoided
  • Common norms, standards and guidelines (preferably international) must be considered if existing
  • Each content EG is responsible for the conformity to the guidelines described in this document and for the professional quality of their area of interest in eCl@ss.
  • Each content EG can create and submit CR that concern the area of interest of other content EG. These CR are in the responsibility of the responsible EG. The responsible EG has to decide on the changes first, before forwarding the CR for the final decision to the QC.

5. If the areas of interest of two content EG are related, the EG have to consolidate their results with each other and inform the eCl@ss office about their results


[edit] Tasks and responsibilities of cross-section expert groups

Currently only one cross-section EG exists in the eCl@ss association, the Center for Research and Development (CRD). This is the central eCl@ss body for the development of the eCl@ss data structure and technical requirements to maintain the eCl@ss standard, i.e. the data model, data base, rules and regulations etc. The CRD is not responsible for the content of the standard itself, but for the structure of the content (not the class structure, which is better described as the class hierarchy).

The eCl@ss association plans to found cross-section EG for the maintenance of cross-segment content like aspects, blocks and properties.

[edit] Center for Quality Control

The Center for Quality Control (CQC) manages and realizes all necessary operational content work including quality control measures on the existing eCl@ss classification system. Among its tasks are:

  • the aquisiton and (re)activation of expert group members
  • the coordination of the eCl@ss expert groups' work
  • the coordination of external experts
  • 1st level support for new or advanced users of the ContentDevelopmentPlatform
  • support of the on time-publication of new eCl@ss releases
  • survey and control of the progress of CR (approval/rework/rejection of CR) within the given deadlines


All CR for updating parts of the eCl@ss classification system are presented to the CQC in a content-checked draft version with final-decision-maturity for quality control, verification and final decision.

The CQC verifies the CR regarding the following aspects:

1. Is final-decision-maturity given, i.e. is a final decision possible?

2. Does the CR influence other areas besides the changed area?

3. Do conflicts exist concerning the responsibility of other EG?

4. Is the CR conform to the guidelines? In case of changes of the hierarchical class structure: does the new hierarchy represent the current market situation?

5. Does the change result in a balanced and logically completed system?

6. Is it a simple correction that can be decided by CQC or a complex tasks for expert groups?

7. Is the right expert working on the CR? Are all relevant EG informed about the CR?

8. Which priority does the CR have?


The CQC decides on the presented CR. It can take the following decisions:

1. The proposal is accepted and will be integrated in a certain future release.

2. The proposal is sent back to the requestor with a distinct reason. The requestor has to rework his CR.

3. The proposal is rejected with a distinct reason.

[edit] Release Roadmap

eCl@ss has defined a transparent release roadmap. Major Releases shall be valid for a longer time period than MinorReleases as the included structural changes result in a higher upgrade effort for users. The possibility to publish all required additions, the removal of all erroneous keywords and values and the correction of clerical errors will be possible each year. Starting with eCl@ss 6.0 a ServicePack exclusively comprises textual changes, i.e. clerical errors and translations, it is therefore language-specific. As it is not integrated into the release roadmap any more, it can be published on demand if needed for a specific language version.

[edit] Published Releases

Release Number Release Type Release date Language version No. of contained classes No. of contained properties No. of contained values
3.0 MAJOR 2000-04-30 not available any more 4.785 2.427 1.986
4.0 MAJOR 2001-03-27 12.915 2.303 1.982
4.1 Minor 2002-02-28 15.315 5.504 3.143
5.0 MAJOR 2003-09-02 24.870 3.667 1.287
5.1 Minor 2004-09-27 25.658 5.525 4.544
5.1.1 Servicepack 2005-09-07 27.216 6.941 4.546
5.1.2 Servicepack 2006-07-12 27.442 6.964 4.712
5.1.3 Servicepack 2006-10-26 30.280 6.967 4.712
5.1.4 Servicepack 2007-07-01 30.329 7.136 4.720
6.0 (replaced by 6.0.1) MAJOR 2008-04-30 32.592 8.653 6.811
6.1 Minor 2009-08-21 32.795 9.910 7.531
6.2 Minor 2009-12-01 32.832 9.919 7.533
7.0 MAJOR 2011-02-15 37.868 15.397 19.123
7.1 Minor 2011-11-30 39.068 15.953 19.874
8.0 MAJOR 2012-12-02 39.041 16.137 13.609
8.1 Minor 2013-12-02 39.085 16.203 13.819
9.0 MAJOR 2014-12-08 Information available in the eCl@ss DownloadPortal 40.870 16.845 14.365
9.1 Minor 2015-11-30 Information available in the eCl@ss DownloadPortal 41.027 16.973 14.456

NOTE 1: Starting with release 7.0 all releases are available in a BASIC and an ADVANCED version. The numbers of contained structural elements refer only to the basic version.

NOTE 2: The number of keywords is language-specific and not mentioned here. eCl@ss 3.0 started with around 8.000 German keywords. eCl@sss 8.0 contains more than 50.000 keywords in both German and English. More information is available in the relevant language version descriptions in the eCl@ss DownloadPortal.

NOTE 3: Starting with release 6.0.1 a ServicePack' definition differs from before 6.0.1, please see above: #Service Pack.

[edit] Planned Releases

eCl@ss will publish

  • one release per year
  • with a fixed publication date on the 30th November each year (or the first working day in December)
  • Every year one MinorRelease will be published, every second year the decision on demand will be taken whether the MinorRelease will be replaced by a MajorRelease depending on the number and type of submitted change requests (the more structural changes are submitted, the higher the demand for a MajorRelease)
  • Currently, the decision on demand will be taken in even years, in odd years a MinorRelease will be published


Table 1: Example: The general eCl@ss roadmap


Figure 3: The current short-term roadmap

Release Roadmap 9 0ff.jpeg


Figure 4: The short-term release milestones

Release Roadmap 10.jpeg

[edit] Known Bugs

eCl@ss is starting to document all known bugs in any available release. This way, users can have an up-to-date overview on technical errors, as well as mistakes in the content of the eCl@ss classification system.

Please have a look at the known bugs page.

[edit] Related information

[edit] References

- CEN (Comité Européen de Normalisation, European Committee for Standardization), Workshop ePDC on Global Multilingual Product Description and Classification for eCommerce and eBusiness. See CWA 15295:2005, p. 35ff.

- www.eclass-contentdevelopmentplatform.com

- www.eclass.eu

Personal tools