Une version est une sorte d'instantané à un moment précis. La version 1.3.1 ne sera plus jamais modifiée, si nécessaire une version 1.3.2 apparaîtra. L'instantané est pris sur une branche, la version 1.3.1 est un instantané pris sur la branche 1.3. Une branche évolue : amélioration et résolution de bugs. Mais une branche ne doit pas évoluer en fonction de ces critères : il n'y aura pas de nouvelles fonctionnalités dans la version 1.3.3 par rapport à la version 1.3.0, seulement du code amélioré, de la résolution de bugs et ainsi de suite.

D'ailleurs, voici les conditions de modification d'une branche stable :

1. Sur une branche stable, pas d'évolution, uniquement des corrections de bugs
2. Sur une branche stable, on corrige les bugs bloquants mais aussi les bugs non bloquants s'ils sont triviaux à corriger
3. Sur une branche stable, dans la mesure du possible, on évite de casser la compatibilité des templates et des langues

Un jour, l'équipe de développement de PhpWebGallery proposera la version 2.0.0, cela signifie un changement complet dans PhpWebGallery comme une refonte complète du code à partir de rien (dans le code) avec une approche de développement orientée objet par exemple.

Voici l'arbre graphique ASCII des branches et versions.

             +------------+
             | branch BSF |
             +------------+
                    |
                    |     +------------+
                    |     | branch 1.3 |
          1.3RC1 => |     +------------+
          1.3RC2 => |           |
                    +-----------+
                    |           | <= 1.3.0
                    |           |
                    |           |
                    |           | <= 1.3.1
                    |           |
                    |           |
                    |           | <= 1.3.2
                    |           |
                    |           |
                    |           |
                    |           |
                    |           |
                    |           | <= 1.3.3
                    |           | <= 1.3.4
BSF_200411201925 => |           
       ...          |
BSF_200412282015 => |
                    |     +------------+
        1.4.0RC1 => |     | branch 1.4 |
        1.4.0RC2 => |     +------------+
        1.4.0RC3 => |           |
                    +-----------+
                    |           | <= 1.4.0
BSF_200504100014 => |           |
                    |           | <= 1.4.1
                    |           |
                    |           |
                    |           | <= 1.4.2
BSF_200505101005 => |           
       ...          |
BSF_200506150635 => |

Un nom de version est toujours composé de 3 nombres, si le dernier est omis, on considère que sa valeur est 0 : la version 1.3 est en fait la version 1.3.0.

• x : le nombre de la version majeure, 1 pour le commencement et pour encore du temps je pense
• y : le nombre de la version mineure, améliorations ajoutées (ou supprimées) entre 2 versions mineures
• z : le nombre de correction, 0 si omis. Pas de nouvelles améliorations entre 2 versions correctives, 'seulement des corrections de bug', les différences entre 1.2 et 1.2.1 sont très mineures mais parfois sont très importantes (une correction d'un bug sur la sécurité à provoquer la mise en place de la version 1.2.1)

Le principal avantage des versions de branches est que l'équipe de développement de PhpWebGallery peut toujours continuer à créer des versions correctives sur une ancienne branche même si une nouvelle branche est disponible. Par exemple, si vous trouvez des bugs dans la version 1.3.2, l'équipe de développement de PhpWebGallery va sûrement résoudre ces bugs pour une version appelée 1.3.3 même si la version 1.4.0 est sortie depuis plusieurs mois.

Il y a deux types de branches dans le modèle de développement de PhpWebGallery : les branches stables et les branches de développement.Il n'y a actuellement qu'une seule branche de développement appelée BSF comme Best So Far (Le mieux jusqu'ici). De cette branche de développement commencent les branches stables comme la branche 1.3 ou la branche 1.4.
La BSF est nommée avec un nom de code attribué à la prochaine version principale qui sera publiée. Ainsi la prochaine version après la 1.6.x s'appelle Alligator. Ce sera sans doute la 1.7, mais ce pourrait être la 1.8 ou la 2.0.

Depuis août 2004, l'équipe projet de PhpWebGallery propose des builds instantanés de développement. Ils sont créés quand une nouvelle amélioration ou une correction de bug est disponible. L'équipe de développement décide quand créer ces builds. Les builds sont principalement créés sur la branche BSF. Le nom des builds contient le nom de la branche et la date de création du build.

Le but de ces builds est de permettre aux utilisateurs avancés de tester les nouvelles fonctionnalités, éventuellement buggées…. Les testeurs peuvent également donner leurs opinions sur le build, reporter les bugs et faire des suggestions pour de futures améliorations.

Pendant la préparation d'une version, celle-ci doit être testée et qualifiée. L'équipe de développement de PhpWebGallery travaille comme suit :

1. Premièrement, une version x.y.zbeta est disponible. Cette version est testée par les plus impatients des utilisateurs. Il est évident pour l'équipe de développement que cette version peut contenir plusieurs bugs. Le but est de les référencer pour préparer la version candidate…
2. La version x.y.zRCn (n allant de 1 à … vous ne pouvez pas savoir jusqu'où ça ira…). Une fois que la plupart des bugs référencés dans la liste faite dans la version x.y.zbeta ont été corrigé, l'équipe de développement propose une Version Candidate 1 (RC1). Les testeurs donnent la liste des bugs trouvés et après un (court) moment, l'équipe de développement propose une Version Candidate 2 (RC2). Et ainsi de suite.
3. La version x.y.z (la finale) doit être exactement la même que la dernière Version Candidate (RC), sans aucun bug connu.

Example : 1.3.0beta » 1.3.0RC1 » 1.3.0RC2 » 1.3.0