Druckbare Version
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
Tag auch,Zitat:
Zitat von DocSteel
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
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.
Ich stimme voll zu!
Man sollte alle Tags dokumentieren; und zwar auf der Homepage und hier im Forum.
jhr
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.
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.
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
Moinmoin,
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...Zitat:
Zitat von dekarl
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 :)!Zitat:
Zitat von dekarl
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...Zitat:
Zitat von dekarl
Viele Grüße
Martin
Moin Ihr Buben,
da steht dann z.B.:Zitat:
Zitat von dekarl
Gute Nacht und viel Spaß beim ausprobierenZitat:
Zitat von svn log
Ich finde diese Lösung sehr schön.
Benutzer: http://www.openttd.org/nightly.php
Entwickler: http://nightly.openttd.org/devs/scoreboard.php
Da stimme ich Dir zu und nein Sourceforge bietet sowas weder in ihrer Plattform (also GForge) noch als Dienst (also Sourceforge) an.Zitat:
Zitat von mdi
Es gibt aber CruiseControl und 1000 andere Softwarepakete für diesen Zweck.
Hier kann ich leider nichts zu sagen. Google hat mir auch nur "das geht nicht" Seiten ausgespuckt.Zitat:
Zitat von mdi
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.Zitat:
Zitat von mdi
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".
Moin,
es ist ein komplettes, lauffähiges monitord-Windows-Installationspaket über die monitord.de-Seite downloadbar (für Win32). Für Linux: Stimmt.Zitat:
Zitat von dekarl
*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.Zitat:
Zitat von dekarl
a) Jemand aus dem derzeitigen Entwicklerkreis. Zuletzt hat Buebchen ein Paket für Windows gebaut.Zitat:
Zitat von dekarl
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