Globaler Skin

[Wurzelgnom]

Original von prissi
...
Es wäre schön, wenn die Leute, die sich betroffen fühlen, das wenigstens testen, bevor hier Zeter und Mordio geschrien wird. Ohne Skin sieht nämlich der Eingangsdialog ziemlich beschieden aus. Auch kann man so die Sprachwahl machen, bevor der Pakauswahldialog kommt, und so den auch übersetzen (das ist auch in Arbeit).
....

Man könnte es testen, wenn man auch weis was wie beabsichtigt ist.

Und das VS nichts eiligeres zu tun hatte als das WindowSkin zu löschen, dürfte auch auf Missverständnis beruht haben.

Ich errinner mich in dieser Beziehung sehr an die Rotation. Da wurden auch alle Setentwickler ohne Vorwarnung überfahren. An den Spätfolgen knappern wir immer noch. Und das war auch ein Steinchen dafür, das MHz nicht mehr hier ist.

Von dem ganzen Frust bei den Spielern durch die fehlerhaften Sets ganz zu schweigen. Zerstörte Spielstände sind sehr Werbewirksam.

[Dwachs]

Original von m_k_w
Das schreit nach einem stable-branch, aber das hatten wir ja auch schonmal (diskutiert)...

Edit: Falls Interesse besteht, könnte ich versuchen, mich mal um einen stable-branch zu kümmern.

Ich denke, dass so ein Interesse besteht. Zumindest sollten wir das mal testen, wie praktikabel bzw arbeitsaufwendig das wirklich ist.

[sojo]

Ich möchte nur mal anmerken, das ich einige kommerzielle Spiele kenne, die mehr Fehler produzieren als die Nightlies von Simutrans. Ich denke, dass das ein Zeichen von Qualität der Programmierung ist und man durchaus auf solche Nightlies mit guter Qualität verweisen kann. Natürlich schadet aber der Hinweis nicht das es "nur" ein Nigtly ist.

[m_k_w]

Original von Dwachs
Ich denke, dass so ein Interesse besteht. Zumindest sollten wir das mal testen, wie praktikabel bzw arbeitsaufwendig das wirklich ist.

Dann würde ich das mal angehen. Ich habe auch die letzten Revisionen nicht verfolgt - kannst du mir sagen, mit welcher ich am besten anfangen sollte? Vll. mit der 2785 = 102.2?

[Dwachs]

Original von m_k_w

Original von Dwachs
Ich denke, dass so ein Interesse besteht. Zumindest sollten wir das mal testen, wie praktikabel bzw arbeitsaufwendig das wirklich ist.

Dann würde ich das mal angehen. Ich habe auch die letzten Revisionen nicht verfolgt - kannst du mir sagen, mit welcher ich am besten anfangen sollte? Vll. mit der 2785 = 102.2?

Ich denke, der stable-Branch sollte vor der Revision mit dem Netzwerk-Modus abzweigen, also zwischen 2787 und 2788.

[prissi]

Das bringt leider nichts, denn die meisten Fehlerverbesserungen kamen danach. Ich habe jedenfalls keinen Bock mehrere Zweige zu pflegen. Es ist schon jetzt schwierig genug, Fehler zu reproduzieren, weil "tritt nur auf mit release xyz, pak128.A mit folgenden eingenen Addons ...." Ich fürchte, das wird dann schlicht und einfach die Entwicklung in den Branch verlagern und man hat wieder das Problem mit vielen Ästen die schnell auseinanderlaufen.

Und bis auf die anfänglichen Timingprobleme hat der Netzwerkmodus ja bisher keine Probleme gemacht (es ist ja nur der Serverteil ausgeschaltet).

Aber wenn das Gefühl geschieht, die Releases sind zu absturzbehaftet, können wir es auch gerne mit einem stabilen Zwei versuchen.

[Hajo]

Original von prissi
Aber wenn das Gefühl geschieht, die Releases sind zu absturzbehaftet, können wir es auch gerne mit einem stabilen Zwei versuchen.

Abstürze treten selten bis nie auf. Aber es finden sich doch recht schnell nach einer Stable einige Fehler.

Wenn m_k_w und Dwachs probieren möchten, nach der nachsten Stable Release einen Bugfix branch anzulegen und zu pflegen, dann haben die beiden meine volle Unterstützung - wenn sich das vielleicht auch nur auf moralische Unsterstützung reduziert, den C++ mag ich nicht mehr programmieren. ich könnte aber vielleicht mit etwas Projekterfahrung, Branchen und Mergen helfen, das mache ich recht häufig als Teil meiner Arbeit.

Solche Branches sollten immer von Stable release abzweigen, und von da ab nur Bugfixes vom Trunk mergen - bis das zu schwer wird, da auf dem Trunk neue Features die Codebasis zu sehr verändert haben. Mit SVN geht das eigentlich ganz gut.

[m_k_w]

Original von prissi
Das bringt leider nichts, denn die meisten Fehlerverbesserungen kamen danach.

Dazu werden die ja gemergt.?

Ich habe jedenfalls keinen Bock mehrere Zweige zu pflegen.

Danke fürs lesen, aber ich hatte geschrieben, dass ich das machen würde. Auf Patchen habe ich zur Zeit sowieso keine Lust, da die Patches unkommentiert ein halbes Jahr rumliegen...

von HajoSolche Branches sollten immer von Stable release abzweigen, und von da ab nur Bugfixes vom Trunk mergen - bis das zu schwer wird, da auf dem Trunk neue Features die Codebasis zu sehr verändert haben. Mit SVN geht das eigentlich ganz gut.

Ich würde es wohl mal mit Git probieren und könnte dann (bei Bedarf) das ganze auch ins SVN packen.

[wernieman]

Ich würde jetzt nicht den Stable Zweig auf ein anderes Versionierungssystem setzen! Eigentlich giebt es doch genau dafür Mittel in SVN!

Wenn die Sourcen auf 2 unabhängigen Versionierungssystemen liegen ... haben wir genau das besprochene Problem der nicht mehr zu definierenden Unterschiede!

[m_k_w]

Original von wernieman
Ich würde jetzt nicht den Stable Zweig auf ein anderes Versionierungssystem setzen! Eigentlich giebt es doch genau dafür Mittel in SVN!

Wenn die Sourcen auf 2 unabhängigen Versionierungssystemen liegen ... haben wir genau das besprochene Problem der nicht mehr zu definierenden Unterschiede!

Ich würde wohl das ganze bloß lokal bei mir mit Git machen und dann ins SVN committen. D.h. der Endabnehmer merkt sowieso nichts davon.