Ich wäre daran interessiert zu wissen, wie Sie da draußen mit der stochern die Versionsnummer für neue Releases Problem umgehen.
Wie gehen Sie mit der Versionsnummer in verknüpften Dateien wie Manpages usw. um?
Die Software wird mit der gnu-Toolkette erstellt, so dass autoconf, automake usw. verfügbar sind und für die Versionsnummer der Anwendung verwendet werden. 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 verwendet, um Versionsnummer und Daten in allen zugehörigen Dateien zu ersetzen. Dieses Ziel könnte einmal am Anfang (direkt nach der Verzweigung) der Entwicklung einer neuen Version aufgerufen werden.
Dann könnte das Projekt mit den richtigen Informationen erstellt werden, wenn Leute einen git-Klon des Projekts machen würden oder wenn ein Release-Tarball fertig ist. Natürlich muss man daran denken, dieses make-Ziel zu starten, wenn man mit der Entwicklung einer neuen Version beginnt.
Eine andere Option wäre, die sed / awk-Ersetzung mit einem Hook für das dist-Ziel durchzuführen. Dies würde jedoch 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 innerhalb des Git-Verlaufs 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 verwenden. Ich sehe beide Vor- und Nachteile in beiden Methoden.
Wie gehen Sie mit der Versionierung verknüpfter Dateien um? Änderst du sie zu Beginn der Entwicklungsphase, änderst du sie kurz vor dem Versand , machst du einen Ersatz oder tust du lieber eine Vorlage?
THX.
Ich denke, dass der übliche Weg dies zu tun ist, Git's Hook-System und m4 oder sed / awk zu benutzen, um das Suchen / Ersetzen wie Sie vorschlagen. Sie brauchen nur ein spezielles Token mit einem Kommentar in jeder Datei (wahrscheinlich in der Kopfzeile).
Hier ist die Referenz auf githooks und hier sind ein paar Seiten, die von Leuten geschrieben wurden, die dasselbe Problem lösen:
Beide hängen davon ab, die Versionsnummer in einer Datei irgendwo in Ihrem Quellbaum zu speichern.
Ich stieß auch auf eine Übernahme namens 0release , die behauptet, die Erstellung von Releases zu automatisieren (und Versionsnummern einzustellen).
Abschließend wird in Bezug auf die Versionsnummern auf einige andere Fragen eingegangen:
Eine gängige Lösung ist heutzutage, AC_INIT mit einem m4_esyscmd Argument aufzurufen, um die VERSION von git zu generieren. Zum Beispiel enthält configure.ac von autoconf die Zeilen:
%Vor%Dabei ist build-aux / git-version-gen ein einfaches Skript, das 'git describe' aufruft, um die Versionsnummer zu generieren. (siehe Gnulib)
Es gibt Nachteile bei diesem Ansatz, aber es kann effektiv sein.
Wir verwenden das klassische major.minor.patch-System, das für die Freigabe von Kandidaten als 'Tag' verwendet wird. Wir haben ein Skript, das ein Commit als Versionsnummer kennzeichnet, anstatt ein git 'tag-Objekt' zu verwenden. Die gesamte Versionsnummerierung erfolgt "von Hand". Es funktioniert einigermaßen gut, weil Die Versionsnummer wird durch die Skripte für die Freigabe auf Staging erstellt, die viel später im Entwicklungsprozess verwendet werden. 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 mit anderen Versionen mit dem gleichen Major, Minor-Tag binär kompatibel sein muss.
Auf diese Weise sollte alles mit einem Tag zumindest erstellt werden, aber es ist möglich oder ziemlich wahrscheinlich, dass es nicht nach Spezifikation funktioniert.
Eine Verfeinerung wäre es, die QA-Abteilung dazu zu bringen, ein signiertes Tag-Objekt für alles zu erstellen, was "QA-genehmigt" ist, aber im Moment verlassen wir uns auf andere Papiere.
Tags und Links linux autotools gnu version-control build-automation