Numéro de version de Bumping pour les nouvelles versions dans les fichiers associés (documentation)

Question

Je serais intéressé de savoir comment vous gérez le en battant le numéro de version pour les nouvelles versions.

Comment gérez-vous le numéro de version dans les fichiers associés comme les pages de manuel, etc.

Le logiciel est construit avec la chaîne d'outils gnu si autoconf, automake, etc sont disponibles et utilisés pour le numéro de version de l'application . Donc, cette information peut être réutilisée.

git est utilisé comme vcs.

Une possibilité serait d'introduire une supplémentaire, nouvelle cible dans Makefile.am qui fait un sed/awk pour remplacer le numéro de version et les dates dans tous les fichiers associés. Cette cible pourrait être appelée une fois au début (juste après branchement) du développement d'une nouvelle version.

Puis le projet pourrait construire avec les informations correctes quand les gens feraient un git clone du projet ou quand une archive de version est faite. Bien sûr, il faut se rappeler d'exécuter cette cible lors du démarrage d'une nouvelle version.

Une autre option serait de faire le remplacement sed/awk avec un crochet pour la cible dist.Mais cela mettrait le dépôt git du projet dans un état où aucun numéro de version correct n'est associé aux fichiers associés.

Je préfère faire la première solution car elle enregistre également le numéro de version correct dans l'historique git. Lorsque vous effectuez un remplacement sed/awk, préférez-vous le faire "in-file" ou avec un template in-file que les outils autoconf/automake font. Je vois à la fois des avantages et des inconvénients dans les deux méthodes.

Comment gérez-vous version des fichiers associés. Les changez-vous au début de la phase de développement, les changez-vous juste avant l'expédition , est-ce que vous remplacez le fichier d'infusion ou préférez-vous utiliser un modèle?

THX.

Answer 1

Je pense que la manière standard de faire ceci est d'utiliser le système de crochet de Git et m4 ou sed/awk pour faire la recherche/remplacer comme vous le suggérez. Vous avez juste besoin d'un jeton spécial avec un commentaire dans chaque fichier (probablement dans l'en-tête).

est ici la référence sur githooks et voici quelques pages écrites par des personnes à résoudre le même problème:

• http://groups.google.com/group/memcached/browse_thread/thread/b02e992ede0f0e89
• http://blog.rfwatson.net/2009/06/03/automatic-version-numbering-using-git/

Ces deux reposent sur le stockage du numéro de version dans un fichier quelque part dans votre arborescence source.

Je suis également tombé sur une prise appelée 0release qui prétend automatiser la création de la version (et le réglage des numéros de version).

Enfin, en ce qui concerne les numéros de version, cette question est abordée dans plusieurs autres questions:

• What version numbering scheme do you recommend?
• How do you do version numbering in an agile project?
• What version number scheme for poorly planned, branched, and schizophrenic application
• Et plus https://stackoverflow.com/search?q=release+numbering

Answer 2

Nous utilisons le classique majeur système .minor.patch, qui est appliqué Pour publier des candidats en tant que 'tag', nous avons un script qui marque un commit comme le numéro de version, plutôt que d'utiliser un 'tag object' git. Toute la numérotation des versions est faite «à la main». Cela fonctionne raisonnablement bien, parce que le numéro de version est créé par les scripts 'release on staging', ce qui est beaucoup plus tard dans le processus de développement. Nous n'utilisons aucun des hooks git, car nous n'en avons pas vraiment besoin, si un commit ne quitte pas l'environnement de développement, il n'a pas besoin d'id autre que son code SHA interne.

Nous essayons de faire en sorte que chaque version de 'patch' soit binaire compatible avec les autres versions avec la même balise majeure majeure. De cette façon, tout ce qui a un tag devrait au moins être construit, mais il est possible ou très probable qu'il ne fonctionnera pas selon les spécifications.

Un raffinement consisterait à demander au service d'assurance qualité de créer un objet d'étiquette signé sur tout ce qui est «approuvé par le contrôle qualité», mais pour l'instant, nous nous en remettons à d'autres documents.

Answer 3

Une solution courante de nos jours est d'invoquer AC_INIT avec un argument m4_esyscmd pour générer la VERSION à partir de git. Par exemple, le configure.ac de autoconf contient les lignes:

 
AC_INIT([GNU Autoconf], 
     m4_esyscmd([build-aux/git-version-gen .tarball-version]), 
     [bug-autoconf@gnu.org]) 

où build-aux/git version-gen est un script simple qui appelle 'git décrire' pour générer le numéro de version. (Voir gnulib)

Cette approche présente des inconvénients, mais elle peut être efficace.