Pour faire simple, je vais détailler comment nous travaillons dans ma boite. Par défaut, tout nouveau développement est fait en "head". Vis à vis de l'extérieur, nous communiquons essentiellement sur le numéro de version majeur+mineur (ex 5.2). Le numéro de majeur est incrémenté lorsqu'il y a vraiment de gros changements sinon à chaque nouvelle version c'est le numéro de mineur qu'on incrémente. Derrière on ajoute le numéro de build et éventuellement un numéro de hotfix. On a donc des numéros complets du genre 5.2.3687.0 (version 5.2, build 3687, non hotfix).
Lorsque la version 5.2, par exemple, est validée par le QA, une branche "5.2" est créée. Les développeurs commencent à travailler sur la future 5.3 et archivent toujours en "head". Ne sont archivées dans la branche que des correctifs à la pince à épiler. Des builds sont faites toutes les nuits plus éventuellement à la demande (principalement hotfix). En plus de ça, il y a un serveur de compilation qui surveille les archivages dans svn et récupère les sources à intervalle régulier pour compiler et avertir les développeurs d'un broken build.
Des branches supplémentaires peuvent être créées pour des développements risqués ou qui ne seront livrée que dans la version n+2. Ces branches sont créées au besoin et elle ne sont pas livrées telle quel mais mergées en head quand elles sont prêtes.
Chaque build livrée au QA est taggée ("5.2.3687.0" par exemple) pour garder une trace de ce qui a été livré. On n'archive jamais dans un tag. C'est un snapshot à un instant T. les correctifs sur la version de prod sont livrés par lot à intervalle assez régulier. Ces corrections sont archivées en branche ("5.2") et mergées dans le trunk. Le client passera peut être de la 5.2.1234.0 à la 5.2.2123.0 sans voir les build intermédiaires qui sont internes. On ne communique pas trop sur les numéros de build mais essentiellement sur la version globale et on parle de "sp1", "sp2",etc pour les lots de correctifs.
Pour le changelog, lors d'un commit les commentaires sont obligatoires. Si un archivage corrige un bug, on met le numéro du bug du genre #4578. Pour générer le changelog entre deux version il suffit de choper la liste des commits et de récupérer dans les messages les numéros de bugs.
# Chez nous
Posté par Croconux . En réponse au message projets & numéros de version - svn & bugzilla. Évalué à 2.
Lorsque la version 5.2, par exemple, est validée par le QA, une branche "5.2" est créée. Les développeurs commencent à travailler sur la future 5.3 et archivent toujours en "head". Ne sont archivées dans la branche que des correctifs à la pince à épiler. Des builds sont faites toutes les nuits plus éventuellement à la demande (principalement hotfix). En plus de ça, il y a un serveur de compilation qui surveille les archivages dans svn et récupère les sources à intervalle régulier pour compiler et avertir les développeurs d'un broken build.
Des branches supplémentaires peuvent être créées pour des développements risqués ou qui ne seront livrée que dans la version n+2. Ces branches sont créées au besoin et elle ne sont pas livrées telle quel mais mergées en head quand elles sont prêtes.
Chaque build livrée au QA est taggée ("5.2.3687.0" par exemple) pour garder une trace de ce qui a été livré. On n'archive jamais dans un tag. C'est un snapshot à un instant T. les correctifs sur la version de prod sont livrés par lot à intervalle assez régulier. Ces corrections sont archivées en branche ("5.2") et mergées dans le trunk. Le client passera peut être de la 5.2.1234.0 à la 5.2.2123.0 sans voir les build intermédiaires qui sont internes. On ne communique pas trop sur les numéros de build mais essentiellement sur la version globale et on parle de "sp1", "sp2",etc pour les lots de correctifs.
Pour le changelog, lors d'un commit les commentaires sont obligatoires. Si un archivage corrige un bug, on met le numéro du bug du genre #4578. Pour générer le changelog entre deux version il suffit de choper la liste des commits et de récupérer dans les messages les numéros de bugs.