Contrôle des versions

Changement apporté du contrôle des version à WET-BOEW et GCWeb.

En vigueur:

Cette nouvelle définition est applicable pour la version et toutes les version subséquente de :

Sommaire de la gestion sémantique de version

Étant donné un numéro de version Majeur.Mineur.Correctif, il faut incrémenter :

  1. le numéro de version Majeur quand il y a des changements non rétrocompatibles,
  2. le numéro de version Mineur quand il y a des ajouts de fonctionnalités rétrocompatibles,
  3. le numéro de version de Correctif quand il y a des corrections d’anomalies rétrocompatibles

Des libellés supplémentaires peuvent être ajoutés pour les versions de pré-livraison et pour des méta-données de construction sous forme d’extension du format Majeur.Mineur.Correctif.

Consulter la version intégrale du document de gestion sémantique de version 2.0.0 plus de plus ample details.

Variante pour le produit WET-BOEW de la gestion sémantique de version

Cette définition s'applique seulement au produit créer à partir des sources: https://github.com/wet-boew/wet-boew et elle est passiblement compatible avec toutes les versions antérieur à v4.0.29.1 publié sous l'identifiant "4.x".

Cette variante inclus l'ajout d'un suffixe numérique afin d'identifier la version architecturale du produit.

Par example, la version 4.0.29.1

Consulter les details de cette variante

Étant donné un numéro de version Architecture.Majeur.Mineur.Correctif, il faut incrémenter :

  1. le numéro de version Architecture quand l'API interne, tel que l'emboîtement des plugiciel, ou quand la méthodolgie d'intégration interne et externe au produit ont des changements non rétrocompatibles,
  2. le numéro de version Majeur quand il y a des changements non rétrocompatibles,
  3. le numéro de version Mineur quand il y a des ajouts de fonctionnalités rétrocompatibles,
  4. le numéro de version de Correctif quand il y a des corrections d’anomalies rétrocompatibles

Des libellés supplémentaires peuvent être ajoutés pour les versions de pré-livraison et pour des méta-données de construction sous forme d’extension du format ARCHITECTURE.MAJEURE.MINEURE.CORRECTIF.

Changement apporté à la spécification (Applicable seulement à WET-BOEW core)

Outre les changements ci-dessous, le reste de la spécification reste intacte.

Modification de la disposition numéro 2 comme suit:

2. Un numéro de version standard doit prendre la forme A.X.Y.Z où A, X, Y et Z sont des entiers non négatifs et ne doivent pas être préfixés par des zéros. A représente l'identifiant de la version architecturale, X représente l’identifiant de version majeure, Y représente l’identifiant de version mineure et Z l’identifiant de version de correction. Chaque élément DOIT s’incrémenter numériquement. Exemple : 2.1.9.0 -> 2.1.10.0 -> 2.1.11.0 -> 3.0.0.1.

Ajout d'une disposition numéro 8-1 à être inséré aprés la disposition 8 et ce lit comme suit:

8-1. L’identifiant de version architecturale A (A.x.y.z | A > 0) doit être incrémenté si des changements non rétrocompatibles sont introduits pour l'emboîtement des plugiciel ou pour la méthodolgie d'intégration interne et externe du produit. Cela peut inclure dans le même temps des changements majeurs, mineurs et des corrections. Les identifiants de version majeur, mineure et de correction doivent être remis à zéro quand l’identifiant de version architecturale est incrémenté.

API publique

L'API publique pour chaque plugiciel est définie par la décision de conception #3 (en anglais seulement).

L'API publique pour la WET-BOEW et pour GCWeb est définie commme qu'il suit:

Le contrôle de version précédant la version 4.0.29.1

Disponible en anglais seulement

Major version (e.g, v3.1.x to v4.0.0)

  • Typical risk of things breaking: High
  • Typical effort to upgrade: High
  • Typical changes:
    • Major framework changes (including major breaking changes)
    • Major markup changes (including major breaking changes)
    • New features and enhancements
    • Bug fixes
  • Typical actions required to upgrade:
    • Modify existing content and code new content differently
    • Major markup changes
    • Add and replace JS, CSS and image files

Minor version (e.g., v3.0.x to v3.1.0)

  • Typical risk of things breaking: Moderate
  • Typical effort to upgrade: Moderate
  • Typical changes:
    • Minor framework changes (possibility of minor breaking changes)
    • Minor markup changes (possibility of minor breaking changes)
    • New features and enhancements
    • Bug fixes
  • Typical actions required to upgrade:
    • Minor markup changes
    • Add and replace JS, CSS and image files

Maintenance version (e.g., v3.1.0 to v3.1.1)

  • Typical risk of things breaking: Low
  • Typical effort to upgrade: Low
  • Typical changes:
    • Minor enhancements
    • Bug fixes
  • Typical actions required to upgrade:
    • Add and replace JS, CSS and image files
Date de modification :