Weiterentwicklung von AccUnit

[Josef Pötzl]

Auszug aus viewtopic.php?f=21&t=171&start=10#p523:

Ich bin nicht sicher ob ich das hier an die richtige Stelle poste, aber ich hätte da eine wichtige Frage:
wann wird es eine Version 1 von AccUnit geben und wird es open source bleiben oder irgendwann käuflich sein bzw gibt es irgendwann einen kommerziellen Support?

AccUnit wird Open Source und frei bleiben.
Ich freue mich auch, wenn nicht nur Paul und ich die Entwicklung vorantreiben müssen.

Die Version 1.0:
Nach MS-Nummerierung, haben wir schon Version 5 oder so.
Ich bin nur mit der Version 1.0 etwas zurückhaltend, da für mich eine 1.0 bedeutet, dass das Tool ausreichend getestet und die Schnittstellen fixiert sind, damit ich nicht schon in ein paar Monaten mit Version 2.0 starten muss.
Außerdem benötigt eine 1.0-Version auch eine Doku.

Meine Vorstellung bezüglich Versionnummern (ab 1.0.0):
Format: a.b.c.d
a ... Eine Änderung bedeutet: nicht mehr (zwangsweise) kompatibel
b ... Abwärtskompatiblität ist gegeben - es kann aber neue Funktionalitäten geben.
c ... Nur kleine Änderungen wie Bug-Behebungen, Behebung vom Layout-Unschönheiten usw.
d ... Subversion-Revision-Nr. (... für Entwickler. um den exakten Code-Zustand erkennen zu können)

mfg
Josef

[Christoph Jüngling]

Einverstanden bis auf "d". Die SVN-Nummer ist nur solange sinnvoll, wie 1. auch wirklich mit SVN gearbeitet wird und 2. diese Nummer maximal 4stellig ist. Ich verwende an vierter Stelle immer die Build-Nummer.

[Josef Pötzl]

Wie kann ich eine Build-Nummer automatisieren, damit sie immer richtig gebildet wird - unabhängig davon, wer gerade die Assembly erzeugt?

[Christoph Jüngling]

Wie kann ich eine Build-Nummer automatisieren, damit sie immer richtig gebildet wird - unabhängig davon, wer gerade die Assembly erzeugt?

Ein paar Ideen dazu ...

Bei einem DVCS (Git, Mercurial, usw.) könnte im Comment-Feld der EXE der Hashwert des Changesets eingetragen werden, aus dem gebaut wird (Mercurial-Extension "keyword"), was die Identifikationsmöglichkeit mit der Revisionsnummer von SVN vergleichbar macht.

Andererseits reicht es vielleicht aus, die Buildnummer nur bei Herausgabe der Software zu setzen und ansonsten auf 0 zu lassen. Dann brauchte man nur einen "Buildserver", der dann über das Repository in der aktuellen Version verfügen müsste.

Für SVN stehe ich aktuell vor dem Problem, dass es zwar zentralisiert ist, aber wir auch aus einem Branch heraus "bauen" und dann immer vergessen, die Buildnummer in den Trunk zu übertragen. Das ließe sich bestimmt automatisieren, indem eine Datei mit der Buildnummer in einem speziell dafür vorgesehenen Repository liegen könnte, das dann von einem per Makefile angestoßenen Prozess die aktuelle holt (ggf. mit Locking), verwendet und um eins erhöht wieder eincheckt.

[Josef Pötzl]

Mir kommt das ziemlich aufwendig vor - nur um nicht die Rev als "Build-Nr" zu verwenden.
Nur weil vielleicht andere VCS keine Rev-Nr. unterstützen, mache ich mir erstmal keine Gedanken, denn AccUnit wird noch lange auf SVN bleiben.
Ich hab zumindest nicht vor bei der momentan riesigen Anzahl an Entwicklern das VCS zu ändern. Wer will kann lokal Git einsetzen und das dann mit dem SVN-Server abgleichen.

Mir sagt auch eine SVN-Rev-Nr in der Versionsnummer viel mehr als irgendeine Build-Nr, wo ich erst wieder nachschauen muss, welche SVN-Rev das war, wenn ich diese Source-Version herstellen will.
Wo ist der Vorteil einer eigenständigen Build-Nr?

BTW: Punkt 2 mit den max. 4 Stellen ist schnell geregelt: dann schneide ich einfach die führenden Stellen ab. Anhand der restlichen Versionsnummern ist dann trotzdem erkennbar, welche SVN-Rev das sein wird.

LG
Josef

[Christoph Jüngling]

Wo ist der Vorteil einer eigenständigen Build-Nr?

Das ist sicher Ansichtssache. Vielleicht war es auch einfach nur die Gewohnheit