Changelog für SVN Versionen

[DocSteel]

Hallo

Ist es viel Aufwand für die Leute die das SVN momentan pflegen ein Changelog zu relaisieren? D.h. wenn es eine neue Version im SVN gibt kurz hier in einen Thread schreiben was sich gegenüber der vorherigen Version geändert hat? Das wäre super :)

Danke & MfG

Doc

[dekarl]

Ist es viel Aufwand für die Leute die das SVN momentan pflegen ein Changelog zu relaisieren?

Tag auch,

das macht Subversion doch automatisch... einfach mal mit "svn log" bzw. "Rechtsklick -> TortoiseSVN -> Show Log" ins Log reinschauen :-)

Jeden commit ins Forum zu stellen halte ich allerdings für vergeudete Liebesmüh'. Da macht es eher Sinn mal ein Trac aufzusetzen um die Logs im Web als RSS Feed zu bekommen. (kannst ja jhr-online mal auf ein Bierchen einladen und überreden Trac o.Ä. einzurichten)

Gruß,
Karl

[Buebchen]

Also ich versuche auch die Änderungen erstmal nur im SVN log zu dokumentieren.

Sobald man aber ein tag erstellt könnte man dazu wirklich ein zusammenfassendes Changelog schreiben. Gerade deswegen, weil im SVN eher für Entwickler dokumentiert wird. Im Changelog eher für den Anwender.

[jhr-online]

Ich stimme voll zu!
Man sollte alle Tags dokumentieren; und zwar auf der Homepage und hier im Forum.

jhr

[mdi]

Moinmoin,

japp, zu Tags hatte ich mich ja in einem anderen Thread schonmal geäußert. Gibt es dazu eigentlich mittlerweile eine Philosophie, wie wir die einsetzen wollen? Ich bin dem aktuellen Entwicklungsstand leider nicht mehr ganz gefolgt :/ - wäre es sinnvoll, einen release canditate zu taggen beim aktuellen Stand, den der "gemeine User" herunterladen kann? Wenn ja, schlage ich vor, auch das Installer-Binary auf den entsprechenden Stand zu bringen, dann ist auch klar, welchen Stand es hat :)!

Martin
PS: Wenn ich den aktuellen Stand taggen und schnell mal das Binary-Kram bauen und veröffentlichen soll, müsste ich das nur wissen.

[dekarl]

Moin,

wie schonmal gesagt, wenn jemand einen nighly build einrichten will unterstütze ich ihn gerne dabei. Ziel wäre dann automatische Erzeugung von Protokollen des Compile Laufes z.B. debian64 Server mit zusätzlichem crosscompile für win32 und debian32.
Das ist für reine Windows Enwickler schon ganz praktisch wenn sie nicht nur um einen Compiletest zu machen eine Linux VM einrichten müssen. Bei der Gelegenheit kann man den Build auch gleich um die Referenzdokumentation (doxygen -> docbook -> PDF z.B.) erweitern und bauen. Noch einen automatischen Upload / Referenz auf monitord.de dazu und "schon" muß sich keiner mehr drum kümmern von Hand mehr oder weniger regelmäßig die Pakete vom trunk zu aktualisieren.

Einziger Haken bei mir, ich habe keinen 64bitter Debian Host im Netz stehen. Also sagt Bescheid wenn irgendwo ein Cruisecontrol o.Ä. läuft wo wir den Monitor drauf bauen können.

Liste der automatisch lieferbaren Pakete:
* Windows 32bit als NSIS Installationspaket (reines msi mit wix geht nicht so einfach, da wix nur unter Windows läuft)
* Windows 32bit als ZIP
* Linux Paket 32/64bit (falls jemand für die entsprechende Distribution die Paketierungsskripte erstellt, da ich hier sehr oft Debian höre wäre das eine Möglichkeit)
* aktuelle Referenzdokumentation (Quellcode Doku, Protokoll Doku, etc.)
* aktuelles Änderungsprotokoll
* Protokolle mit Fehlern / Warnungen beim Kompilieren unter verschiedenen Betriebssystemen

Gruß,
Karl
PS: Debian 64 ist nur ein Beispiel, da bekommt man die Pakete bis hin zur win32 Paketierung fertig mitgeliefert.

[dekarl]

Moin Ihr Buben,

einfach mal mit "svn log" bzw. "Rechtsklick -> TortoiseSVN -> Show Log" ins Log reinschauen :-)

da steht dann z.B.:

------------------------------------------------------------------------
r327 | dekarl | 2008-07-24 00:06:29 +0200 (Do, 24. Jul 2008) | 1 line

FMSCrusader Protokoll um Empfang von manuellen Statusänderungen vom FMSCrusader erweitert.
------------------------------------------------------------------------
r326 | dekarl | 2008-07-24 00:04:10 +0200 (Do, 24. Jul 2008) | 2 lines

FS#26 Segfault beim FMS-Demod in mac()
der Absturz sollte jetzt nicht mehr auftreten
------------------------------------------------------------------------
r315 | dekarl | 2008-07-23 08:34:35 +0200 (Mi, 23. Jul 2008) | 4 lines

Doxygen Konfiguration aktualisiert (keine Aenderung)
Doxygen Kommentare angepasst damit Doxygen die auch versteht
------------------------------------------------------------------------
r313 | dekarl | 2008-07-20 01:34:52 +0200 (So, 20. Jul 2008) | 1 line

Debugging Ausgabe für unbekannte Kommandos vom Crusader / FMS32 hinzugefügt
------------------------------------------------------------------------
r312 | dekarl | 2008-07-20 01:02:43 +0200 (So, 20. Jul 2008) | 1 line

FIX: beim Installieren des Windows Dienst mit "--install -c " wurde trotzdem die ConfigDatei als monitord.xml im Verzeichnis der EXE gesucht. (Jetzt geht es zumindest mit absoluten Pfaden)
------------------------------------------------------------------------
r311 | dekarl | 2008-07-19 23:23:55 +0200 (Sa, 19. Jul 2008) | 6 lines

FIX: const bei der Parameterdefinition
FIX: Stringvergleich mit strcmp anstatt ==
FIX: workaround fuer Kommandozeilenparameter, die wurden aus der Config ueberschrieben

Gute Nacht und viel Spaß beim ausprobieren