Les exécutables doivent-ils contenir des numéros de version dans leurs noms?

Je développe un certain serveur. Jusqu’à présent, deux versions ne pouvaient pas être installées en même temps. Nous changeons maintenant cela et la question a été posée: le numéro de version doit-il être ajouté aux composants du serveur ou non? Le serveur contient 3 exes et 5 dlls (certains COM, certains VC ++ natifs). Est-ce que tout ou partie des noms doit contenir la version ( Serv71.exe , module71.dll ) ou non?

Du côté des pros, cela devrait faciliter la gestion du serveur. Si une certaine instance se comporte mal, elle serait identifiable dans le gestionnaire de tâches. De plus, il est impossible qu’une mauvaise installation se termine par des versions de composants mixtes sans que cela soit remarqué.

Par contre, cela rendrait le développement un peu plus difficile. Le serveur n’est pas un produit autonome, mais une partie de notre infrastructure d’applications. Cela signifie qu’il obtient la version de l’application principale. Cela dit, un certain composant devra obtenir un nom différent même s’il n’a pas du tout changé entre les versions.

Dans l’ensemble, ce n’est pas un problème crucial. Nous pouvons probablement nous entendre avec les deux manières. Cela dit, j’aurais peut-être manqué un argument gagnant en faveur de l’une des stratégies. Quel est le choix commun? Que faire?

Edit: Je suis familier avec la gestion des versions de métadonnées de fichiers et de COM, et je suis d’accord sur le fait que la gestion des versions des noms de fichiers est redondante. J’essaie de comprendre ce qui est plus important – les frais généraux de redondance constante, ou le gain rare en maintenance.

Pour les API COM, vous disposez de toutes les informations de version dont vous avez besoin dans vos bibliothèques. Je trouverais que nommer ces DLL avec des numéros de version redondants au mieux, au pire déroutant (du moins si les numéros de version sont désynchronisés). Je suis favorable à l’ajout d’un identifiant de version aux noms d’interface et de coclars à chaque fois que je souhaite un chemin de mise à niveau clair et que des modifications soient apscopes.

Pour les API DLL binarys simples, append des numéros de version est une idée, mais pas une de celles que j’ai déjà bien exécutées (et assez terriblement exécutées dans ces anciennes DLL d’exécution VB 16 bits!). Ont-ils des API claires et délimitées, ou exposent-ils des dizaines de fonctions? Vous allez avoir des problèmes pour distinguer un mineur d’un changement si les interfaces sont grandes. Une fois que vous commencez à étiqueter les versions de cette façon, vous devez être cohérent. Chaque changement de version signifiera que les clients reliant statiquement doivent être recompilés (et par conséquent la version reclassée eux-mêmes). Le problème potentiel ici est que vous obtenez beaucoup de «bruit de version» , masquant les changements importants.

Les binarys Windows contiennent des métadonnées de version (la structure VERSIONINFO ). Comme le dit LeJeune, il s’agit d’un itinéraire bien connu, bien que celui-ci ne provoque pas automatiquement des erreurs lorsque vous associez des éléments inappropriés. Cependant, c’est un outil que vous pouvez utiliser relativement facilement pour prendre en charge les schémas de gestion de configuration dont vous avez besoin.

Généralement, les informations de version font partie des métadonnées (informations sur les fichiers étendues) de la DLL et ne font pas partie du nom du fichier.

Le processus de maintenance est plus facile. Les programmes d’installation savent comment utiliser ces informations lorsque vous mettez à niveau / remplacez un fichier binary existant. Si vous avez besoin de publier une nouvelle version de la DLL, vous n’avez pas besoin de recomstackr / relier votre exe.

En règle générale, n’essayez pas d’inventer de nouveaux mécanismes. Utilisez ceux existants.

Je dirais que si les DLL fournissent différentes API dans différentes versions, le numéro de version doit être ajouté au nom de fichier. Pour les exécutables, cela n’a pas d’importance. Si l’exécutable interagit en utilisant une interface spécifiée, et que cela change, j’utiliserai également le numéro de version dans les noms de fichiers des exécutables.

“Par contre, cela rendrait le développement un peu plus difficile.”

Pas tout à fait vrai. Il expose un problème que vous avez déjà – en gardant toutes les versions de tous les composants alignés.

Vous devez vous assurer que l’infrastructure des applications dans son ensemble a toutes les versions appropriées de tous les composants.

Facilitez la tâche en étiquetant correctement chaque pièce et en fournissant un rapport de configuration indiquant quelles versions sont à jour et quelles versions doivent être utilisées ensemble.