2009-05-16 6 views
1

Nous avons un produit qui a plusieurs extensions, chacune ayant son propre numéro de version. (Plus précisément, nous avons une application xulrunner avec plusieurs extensions). Le gestionnaire d'extension pour xulrunner fournit une fonctionnalité de mise à jour de sorte qu'il appelle une fonction chaque fois que le numéro de version de cette extension a augmenté. Cela nous donne un moyen de faire le nettoyage nécessaire avec la mise à jour.Quelles stratégies existent pour gérer les mises à jour sur plusieurs sous-produits et plusieurs versions?

Cependant, il est devenu très difficile de trouver un bon moyen de garder une trace des extensions qui nécessitent une augmentation du numéro de version et celles qui sont restées essentiellement inchangées. Le meilleur processus que nous pouvons imaginer est 1) ajouter un travail initial lors de la fermeture des tickets (chaque ticket peut avoir une série de drapeaux indiquant les extensions à modifier) ​​
2) écrire des requêtes qui recherchent les tickets ayant des modifications dans une extension 3) Mise à jour des numéros de version d'extension dans l'ensemble du produit

Tout cela semble fastidieux à la fois pendant le développement et au moment de la publication - et sujet aux erreurs. Aucune suggestion?

Répondre

0

Il semble que vous vous penchiez sur l'utilisation de vos tickets de travail pour identifier les modifications apportées à vos extensions. Je me demande si vous devriez le regarder de l'autre côté et utiliser votre système de contrôle de version pour identifier où les changements ont été faits. Votre historique des versions devrait vous fournir tous les renseignements dont vous avez besoin sur ce qui a changé en fonction des changements réellement faits et publiés. Il fournira également une certaine quantité de vérification que la portée du changement prévu correspond à la portée du changement effectué. Sur la base de ces informations, vous pouvez implémenter vos décisions de modification de version.