L'intégralité du code source d'Ovidentia est disponible sur un dépôt Git.

Prenez note que ce dépot Git peut contenir du code non testé et par conséquent pourrait rendre votre installation d'Ovidentia instable.
Si vous souhaitez utiliser Ovidentia dans un environnement de production, nous vous recommandons de télécharger la dernière version stable dans l'espace de téléchargement.

Pour récupérer le version en cours de développement d'Ovidentia, exécutez la commande suivante :

git clone https://bitbucket.org/cantico/ovidentia.git

 

Vous pouvez également parcourir le dépôt Git d'Ovidentia et télécharger la version en cours de développement en allant sur Bitbucket.

Le travail dans Git s'effectue sur deux types de branches : stable et instable. Les caractéristiques de ces types de branches sont les suivantes :
 

Les branches stables

Elles sont nommées PATCHS-X-Y-0 dans Git. Ces branches ne contiennent que des versions stables. Toutes les versions d'une branche stable ne contiennent que des corrections de bugs par rapport à la version initiale de la branche.

La branche instable

Elle est nommée HEAD dans Git. C'est la branche où ont lieu les nouveaux développements. Elle contient des versions bêta (dont le dernier chiffre est supérieur ou égal à 90) considérées comme instables et des versions release candidate (dont le dernier chiffre est supérieur ou égal à 100) considérées comme stables du point de vue des fonctionnalités mais non testées.

Les modifications peuvent avoir lieu en parallèle sur les différentes branches. En pratique elles n'auront lieu que sur la dernière branche stable et la branche instable : correction de bugs sur la dernière branche PATCHS-X-Y-0 et ajout de nouvelles fonctionnalités sur HEAD.

En effet, par principe lorsqu'une nouvelle branche PATCHS-X-Y-0 est créée,  la branche PATCHS précédente est "fermée" : il n'y aura plus de nouvelle version taggée sur cette branche. Cependant, des correctifs pourront être ponctuellement committés.

Les numéros identifiant les versions d'ovidentia sont composés de trois chiffres séparés par des points. Ils se lisent de la manière suivante :

6 .  5 .  2
|     |     |
|     |     |_ 2ème version de maintenance
|     |
|     |___ 5ème version mineure
|
|_____ 6ème version majeure

• La version de maintenance est incrémentée lors de la correction de bugs.
• La version mineure est incrémentée lors d'ajout d'une ou plusieurs petites fonctionnalités.
• La version majeure est incrémentée lors d'ajout de fonctionnalités importantes.

Versions stables

Elles ont un numéro de maintenance strictement inférieur à 90 (Exemple : 6.5.2). Toutes les versions stables ayant les mêmes numéros de versions majeures et mineures disposent du même ensemble de fonctionnalités, proposent les mêmes interfaces aux utilisateurs (hormis les corrections de bugs d'affichage) et gardent la même documentation (hormis les corrections et les ajouts sur des fonctionnalités pas ou peu documentées).

Versions bêta

Elles ont un numéro de maintenance supérieur ou égal à 90 et strictement inférieur à 100 (Exemple : 6.5.90 pour la première version bêta de la future version 6.6.0). Les versions bêta intègrent tout ou partie des nouvelles fonctionnalités en cours de développement dans le noyau. Elles peuvent être distribuées mais - étant notoiremment instables - elles ont essentiellement pour but d'offrir un aperçu des évolutions du noyau et de fournir une base commune pour la recherche de bugs.

Versions Release Candidate

Elles ont un numéro de maintenance supérieur ou égal à 100 (Exemple : 6.5.100 pour la première version Release Candidate de la future version 6.6.0). Les versions Release Candidate (rc) succèdent aux versions bêta. A partir de la première Release Candidate (rc1), les ajouts fonctionnels sont prohibés (période dite de feature freeze) jusqu'à la création de la prochaine branche stable.