Politique de versions

À quoi s’attendre lors de la mise à niveau de Elgg.

Nous adhérons au versionnage sémantique.

Suivez le blog pour rester à jour sur les dernières versions.

Versions de correctifs/bugfix (2.1.x)

Toutes les deux semaines.

Les publications de correctifs sont effectuées régulièrement pour s’assurer que Elgg reste stable, sécurisé et exempt de bogues. Plus le troisième chiffre est élevé, plus la version est testée et stable.

Dans la mesure où les versions correctives de bogues se concentrent sur la correction des bogues et évitent d’apporter des changements majeurs, les thèmes et les plugins doivent fonctionner de version corrective en version corrective.

Versions mineures/fonctionnalités (2.x.0)

Tous les trois mois.

Chaque fois que nous introduisons de nouvelles fonctionnalités, nous incrémentons le numéro de version du milieu. Ces versions ne sont pas aussi matures que les correctifs, mais sont considérées comme stables et utilisables.

Nous faisons tous les efforts possibles pour être rétrocompatibles dans ces versions, de sorte que les plugins devraient fonctionner de version mineure en version mineure.

Toutefois, les plugins pourraient devoir être mis à jour pour utiliser les nouvelles fonctionnalités.

Versions Majeures / de rupture (x.0.0)

Chaque année.

Inévitablement, l’amélioration de Elgg nécessite des changements non rétro-compatibles et une nouvelle version majeure est alors publiée. Ces versions sont des occasions pour l’équipe de base d’apporter des changements stratégiques et de rupture à la plateforme sous-jacente. Les thèmes et les plugins des anciennes versions ne sont pas censés fonctionner sans modification sur les différentes versions majeures.

Nous pouvons supprimer des APIs obsolètes, mais nous ne supprimerons pas d’APIs sans les avoir d’abord dépréciées.

Les dépendances de Elgg peuvent être mises à niveau par leur version majeure ou supprimées entièrement. Nous ne supprimerons pas de dépendance avant une version majeure, mais nous ne rendons pas obsolète - « deprecate » - les dépendances ou ou n’émettons pas d’avertissement avant de les supprimer.

Votre package, plugin ou application doit déclarer ses propres dépendances directement afin que cela ne cause pas de problème.

Versions Alphas, Betas, et candidates RC - Release Candidates

Avant les versions majeures (et parfois avant les versions de fonctionnalités), l’équipe du noyau offrira une pré-version de Elgg pour obtenir des tests et des commentaires dans le monde réel sur la version. Ces versions sont destinées à des tests seulement et ne doivent pas être utilisées sur un site en production.

SemVer 2.0 ne définit pas de signification particulière pour les pré-versions, mais nous abordons les versions alpha, bêta et rc avec ces indications générales :

Une pré-version -alpha-X signifie qu’il y a encore des modifications de rupture prévues, mais l’ensemble des fonctionnalités de la version est gelé. Aucune nouvelle fonctionnalité ou modification de rupture ne peut être proposée pour cette version.

Une pré-version -beta.X signifie qu’il n’y a plus de modification de rupture connue à inclure, mais qu’il reste des régressions connues ou des bogues critiques à corriger.

Une pré-version -rc.X signifie qu’il n’y a plus de régression connue ou de bogue critique à corriger. Cette version pourrait devenir la version stable finale de Elgg si aucun nouveau blocage n’est signalé.

Rétro-compatibilité

Certaines parties du système ont besoin de clarifications supplémentaires si nous voulons être rétro-compatibles. Tout ce qui est considéré comme une API publique doit respecter les règles de rétro-compatibilité qui font partie du versionnage sémantique.

Classes et fonctions

Les classes et fonctions marquées @internal ne sont pas considérées comme faisant partie de l’API publique et peuvent être modifiées/supprimées à tout moment. Si une classe est marquée @internal, toutes les propriétés et méthodes de cette classe sont considérées comme une API privée et peuvent être modifiées/supprimées à tout moment.

Gestionnaires d’événements

Tous les rappels d’événement ne doivent jamais être appelés directement mais uniquement en déclenchant l’événement.

Le nom de la fonction de rappel est considéré comme une API dans le sens où les développeurs de plugins doivent être en mesure de compter sur le fait qu’ils peuvent (dé-)enregistrer une fonction de rappel. Ceci ne s’applique que si la fonction de rappel sert toujours le même but. Si une fonction de rappel devient obsolète, elle peut être supprimée du système.

Avertissement

Les exceptions à ces règles sont les fonctions de rappel liées aux événements system, ces fonctions de rappel peuvent être renommées / supprimées à tout moment.

  • plugins_load

  • plugins_boot

  • init

  • ready

  • shutdown

  • upgrade

Suite de tests

Les fichiers de la suite de tests Elgg PHPUnit ne sont pas considérés comme faisant partie de l’API publique et peuvent être modifiés/supprimés à tout moment.

Vues

  • Les noms de vue sont des APIs.

  • Les arguments de la vue (tableau $vars) sont des API.

  • La suppression de vues ou le changement de nom de vues suit les stratégies de dépréciation de l’API.

  • L’ajout de nouvelles vues nécessite une modification mineure de la version.

  • La sortie des vues n’est pas une API et peut être modifiée entre deux versions de correctifs.