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.

[jhr-online]

Ich bin theoretisch in der Lage, Debian-Pakete zu bauen. Der Server, auf dem die monitord.de-Sachen liegen ist ein 32Bit-vServer. Zu Hause hab ich auch "nur" ein 32Bit-Debian laufen. Eine Neuinstallation wäre zwar mal angemessen, aber ich hab keine Zeit, also auch kein 64Bit zur Hand...

jhr

[mdi]

Moinmoin,

wie schonmal gesagt, wenn jemand einen nighly build einrichten will unterstütze ich ihn gerne dabei.

grundsätzlich eine gute Idee, wenn wir so weit gehen wollen, würd ich aber wieder fragen: Gibt nicht z.B. SourceForge soetwas schon her? Man muss ja das Rad nicht neu erfinden...

Ziel wäre dann automatische Erzeugung von Protokollen des Compile Laufes z.B. debian64 Server mit zusätzlichem crosscompile für win32 und debian32.

Cross-Compiling mit MySQL-Support hat bei mir nicht geklappt (auf Ubuntu32 für win32). Ich habe dahingehend auch Infos bei MySQL.org gefunden, dass das wohl derzeit oder auch dauerhaft nicht geändert wird. Wenn es doch eine Möglichkeit gibt, wäre ich für Infos dankbar :)!

(...) 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.

Das ist der zweite Aspekt, der mir dazu einfällt: Wie oft wäre soetwas notwendig? Wenn jemand wirklich die Sourcen aus dem SVN auscheckt, dann kann der auch vermutlich selber kompilieren (Anleitung gibts ja). Wenn er das nicht tut, kanns auch die Version des letzten Tags in /tags sein, meiner Meinung nach. So oft gibts ja derzeit keine grandiosen Änderungen. Gut, nach Fix eines bösen Bugs muss man dann halt updaten, nunja...

Viele Grüße
Martin

[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

[dekarl]

Ich finde diese Lösung sehr schön.
Benutzer: http://www.openttd.org/nightly.php
Entwickler: http://nightly.openttd.org/devs/scoreboard.php

grundsätzlich eine gute Idee, wenn wir so weit gehen wollen, würd ich aber wieder fragen: Gibt nicht z.B. SourceForge soetwas schon her? Man muss ja das Rad nicht neu erfinden...

Da stimme ich Dir zu und nein Sourceforge bietet sowas weder in ihrer Plattform (also GForge) noch als Dienst (also Sourceforge) an.
Es gibt aber CruiseControl und 1000 andere Softwarepakete für diesen Zweck.

Cross-Compiling mit MySQL-Support hat bei mir nicht geklappt (auf Ubuntu32 für win32). Ich habe dahingehend auch Infos bei MySQL.org gefunden, dass das wohl derzeit oder auch dauerhaft nicht geändert wird. Wenn es doch eine Möglichkeit gibt, wäre ich für Infos dankbar :)!

Hier kann ich leider nichts zu sagen. Google hat mir auch nur "das geht nicht" Seiten ausgespuckt.

Das ist der zweite Aspekt, der mir dazu einfällt: Wie oft wäre soetwas notwendig? Wenn jemand wirklich die Sourcen aus dem SVN auscheckt, dann kann der auch vermutlich selber kompilieren (Anleitung gibts ja). Wenn er das nicht tut, kanns auch die Version des letzten Tags in /tags sein, meiner Meinung nach. So oft gibts ja derzeit keine grandiosen Änderungen. Gut, nach Fix eines bösen Bugs muss man dann halt updaten, nunja...

Auf den meisten Unixkisten ist ja ein cc drauf, aber was ist mit Windows. Da wird vom 2er noch kein einziges Release haben muß *jeder* der sich die neue Version mal ansehen will einen Compiler installieren. Damit fallen dann sicher 3/4 der Interessenten weg weil das zu umständlich ist.
Wir haben tags? Es bleibt aber trotzdem bei, "jemand" muß halt etwas irgendwie kompilieren und irgendwo hochladen... a) Wer ist jemand? b) Wie stellst Du sicher das ein korrektes Paket gebaut wird? c) und darf der das an die richtige Stelle hochladen?
Für mich hört sich das an wie "zu umständlich und deshalb wird es nicht gemacht".

[mdi]

Moin,

Auf den meisten Unixkisten ist ja ein cc drauf, aber was ist mit Windows. Da wird vom 2er noch kein einziges Release haben muß *jeder* der sich die neue Version mal ansehen will einen Compiler installieren. Damit fallen dann sicher 3/4 der Interessenten weg weil das zu umständlich ist.

es ist ein komplettes, lauffähiges monitord-Windows-Installationspaket über die monitord.de-Seite downloadbar (für Win32). Für Linux: Stimmt.

Wir haben tags?

*fg*. Nein. Bisher nicht. IIRC. Ich hielte es aber für sinnvoll, sofern sich hier Stimmen finden, die sagen: "Ja, im Moment ist der monitord recht stabil und lauffähig, die Doku hat einen brauchbaren Stand erreicht, Bastler können das Ding nutzen", setzen wir einen Tag "2.0RC1" oder soetwas, der die aktuellen Sourcen quasi einfriert.

Es bleibt aber trotzdem bei, "jemand" muß halt etwas irgendwie kompilieren und irgendwo hochladen... a) Wer ist jemand? b) Wie stellst Du sicher das ein korrektes Paket gebaut wird? c) und darf der das an die richtige Stelle hochladen?
Für mich hört sich das an wie "zu umständlich und deshalb wird es nicht gemacht".

a) Jemand aus dem derzeitigen Entwicklerkreis. Zuletzt hat Buebchen ein Paket für Windows gebaut.
b) Ja, das ist ein Problem. Ist es aber bei den automatischen Builds auch, oder täusche ich mich da? Gut, automatisiert ist die Wahrscheinlichkeit geringer, dass vorher noch was reingepfuscht wird, weil direkt vor dem Kompilieren ein SVN co gemacht wird...
c) Das ist die Frage, sollte sich aber organisieren lassen.

"Zu umständlich": Als Begründung halte ich das für nicht so richtig stichhaltig, weil sich beim derzeitigen Entwicklungstempo der Zeitaufwand für den Paketbau arg in Grenzen halten dürfte. Dennoch ist der Ansatz keineswegs falsch!

Viele Grüße
Martin