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 "MajorRelease Number" (x.0) and a "MinorRelease Number" (n.x). A Service Pack 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 "MajorRelease Number" shows that changes have occurred that are not compatible to the last release. The publication of a MajorRelease can result in the fact that the assignment of existing data to the new eCl@ss release has to be checked and corrected. The "MajorRelease 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 "MinorRelease Number" is changed, existing data can still be used without changes, i.e. changes are upward compatible. The "MinorRelease Number" is raised when a new release is published that only consists of new structural elements or editorial changes. The "MinorRelease Number" is mandatory for every release and is automatically created by the eCl@ss ContentDevelopmentPlatform. In case the "MajorRelease Number" will automatically be set to "0".||no|
|Service Pack Number||CHAR(3)||The "ServicePack Number" is raised with the publication of a new language version. The change of the "ServicePack Number" is not bound to changes of the content, but exclusively to editorial changes that also include translations. The "ServicePack 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 the case the "MinorRelease Number" is changed the "ServicePack Number" will automatically be set to "0".||yes|
EXAMPLE: MinorRelease 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.
New or edited language variants are developed on demand and are therefore not included in the release roadmap.
Figure 1: Example of an eCl@ss ReleaseNumber
Version and Revision
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 increasement does not imply changes of the content. If a version number is increased, the MinorRelease (and ServicePack) 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 was 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 of the release was processed in the database||in the dictionary (XML), CSV: will be added starting with Release 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|