Bumping Versionsnummern für neue Releases in zugehörigen Dateien (Dokumentation)

Question

Ich wäre daran interessiert zu wissen, wie Sie da draußen mit der stoßen die Versionsnummer für neue Releases Problem.

Wie beurteilen Sie die Versionsnummer in der zugehörigen Dateien, wie man Seiten handhaben usw.

Die Software wird mit der Gnu-Werkzeugkette baut so autoconf, auto, etc. sind vorhanden und für die Versionsnummer der Anwendung verwendet . So können Informationen wiederverwendet werden.

git wird als VCS verwendet.

Eine Möglichkeit wäre ein zusätzliches, neues Ziel in Makefile.am einzuführen, das eine sed/awk zum Ersetzen der Versionsnummer und der Daten in allen zugehörigen Dateien ausführt. Dieses Ziel könnte einmal zu Beginn (gleich nach der Verzweigung) der Entwicklung eines neuen Releases aufgerufen werden.

Dann könnte das Projekt mit den richtigen Informationen erstellen, wenn Leute einen Git Klon des Projekts tun würden oder wenn ein Release Tarball getan wird. Natürlich muss man daran denken, dieses Make-Ziel zu starten, wenn man mit der Entwicklung einer neuen Version beginnt.

Eine andere Möglichkeit wäre, die sed/awk-Ersetzung mit einem Haken für das dist-Ziel durchzuführen. Dies würde das git-Repository des Projekts in einen Zustand versetzen, in dem keine korrekte Versionsnummer den zugehörigen Dateien zugeordnet ist.

Ich bevorzuge die erste Lösung, da es auch die korrekte Versionsnummer in der Git-Geschichte aufzeichnet.

Wenn Sie einen sed/awk-Ersatz machen, tun Sie es lieber "in-file" oder mit einer Vorlage in der Datei, die die autoconf/automake tools machen. Ich sehe beide Vor- und Nachteile in beiden Methoden.

Wie behandeln Sie Versionierung der zugehörigen Dateien. Ändern Sie sie am Anfang der Entwicklungsphase, ändern Sie sie, wenn sie kurz vor Versand sind, tun Sie infile Ersatz oder bevorzugen Sie eine Vorlage?

THX.

Answer 1

Ich denke, dass der Standard Weg dies zu tun ist, Git's Hook-System und m4 oder sed/awk zu verwenden, um die Suche/ersetzen, wie Sie vorschlagen. Sie brauchen nur ein spezielles Token mit einem Kommentar in jeder Datei (wahrscheinlich in der Kopfzeile).

Hier ist der Verweis auf githooks und hier ein paar Seiten von Leuten geschrieben das gleiche Problem zu lösen:

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

Beide verlassen, um die Versionsnummer in einem auf Speicher Datei irgendwo in Ihrem Quellbaum.

Ich stieß auch auf eine Aufnahme namens 0release, die behauptet, Release-Erstellung zu automatisieren (und Versionsnummern einstellen).

Schließlich bezüglich Release-Nummer, diese in mehreren anderen Fragen gerichtet:

• 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
• Und mehr https://stackoverflow.com/search?q=release+numbering

Answer 2

Wir verwenden die klassische Haupt .minor.patch-System, das angewendet wird Um Kandidaten als "Tag" freizugeben, haben wir ein Skript, das ein Commit als Versionsnummer markiert, anstatt ein git 'tag object' zu verwenden. Die gesamte Versionsnummerierung erfolgt "von Hand". Es funktioniert ziemlich gut, weil die Versionsnummer von den 'Freigabe auf Staging'-Skripten erstellt wird, die viel später im Entwicklungsprozess ist. Wir kümmern uns nicht darum, einen der Git-Hooks zu verwenden, da wir es nicht wirklich brauchen, wenn ein Commit nicht die Entwicklungsumgebung verlässt, dann braucht er keine ID, außer seinem internen SHA-Code.

Wir versuchen zu erzwingen, dass jede "Patch" -Release binär kompatibel mit anderen Versionen mit dem gleichen Major, Minor-Tag sein muss.

Auf diese Weise sollte alles mit einem Tag zumindest bauen, aber es ist möglich oder sehr wahrscheinlich, dass es nicht zur Spezifikation funktioniert.

Eine Verfeinerung wäre, die QA-Abteilung dazu zu bringen, ein signiertes Tag-Objekt für alles zu erstellen, das 'QA-genehmigt' ist, aber dafür verlassen wir uns auf andere Papiere.

Answer 3

Eine gängige Lösung ist heutzutage, AC_INIT mit einem m4_esyscmd Argument aufzurufen, um die VERSION von git zu generieren. Zum Beispiel autoconf die configure.ac enthält die folgenden Zeilen:

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

wo build-aux/git-Version-gen ein einfaches Skript, das 'git beschreibt' ruft die Versionsnummer zu generieren. (siehe gnulib)

Es gibt Nachteile bei diesem Ansatz, aber es kann effektiv sein.