Versionsmanagement datfile

Hallo!
Seht Ihr eine Möglichkeit für das datfile ein Versionsmanagemant zu installieren?
So wie ich das beobachte, wird nicht in jeder NB das datfile geändert.
Durch seinen zahlreichen Einzeldateien braucht es mit Abstand die meiste Zeit beim PDA-Update. Deswegen fände ich es gut, wenn ich erkennen könnte, ob dieser Aufwand nötig ist oder ob sich nur die exe bzw jar geändert hat.
Ansonsten: Frohe Ostern!

Vielleicht könnte man eine Textdatei dazulegen, die angibt, von welchem Versionsstand sie ist. Oder man schreibt es in den Dateinamen. Mal sehen. Falls bald wieder eine stable erscheint sind die NBs aber für den Normaluser nicht mehr so relevant.

MiK schrieb:

Falls bald wieder eine stable erscheint sind die NBs aber für den Normaluser nicht mehr so relevant.

Zum Vergrößern anklicken....

Woher nimmst Du die kühne Hoffnung, dass die Fehler weniger werden, nur weil ne 1 vor dem Versionskomma steht? Nach der Version ist vor der Version

Engywuck

Die 1.0 wird eine Version sein, die man ohne größere Probleme über eine längeren Zeitraum verwenden kann. Klar wird es noch kleine Fehler geben und es werden danach wieder neue Features dazukommen. Wenn man die testen möchte muss man eben zu den NBs greifen. Aber die breite Masse wird eben das stable benutzen.

MiK schrieb:

Klar wird es noch kleine Fehler geben und es werden danach wieder neue Features dazukommen.

Zum Vergrößern anklicken....

Ist denn geplant, die Entwicklungslinie von der Fehlerbeseitigungslinie zu trennen?
Ansonsten würde doch z.B. eine Änderung der Webseiten bei Groundspeak zumindest die Änderung der Spider-Datei nach sich ziehen. Also entweder neue Version der Exe, oder nur einzelne Dateien patchen? Wenn die Exe ausgetauscht wird und Entwicklung/Fehlerbeseitigung sind nicht getrennt, hat man natürlich das Problem, dass man wieder die neuen Features (mit neuen Fehlern) drin hat.

Engywuck (auch in der Softwareentwicklung arbeitend)

ich denke nur getrennt macht Sinn. In der 1.0 sollten nur noch Bugs bereinigt werden und alle neuen Features kommen in eine Version >1.0.

ich sehe nicht, das wir in der Lage sind, 2 Versionen getrennt zu pflegen.
Was möglich sein wird, ist, die spider.def solange für beide Versionen zu verwenden, bis die Änderungen auf der Website eine Änderung des Java-Codes erfordern.
In diesem Fall werden die Nutzer wieder auf die Nightly Builds zurückgreifen (müssen), um spidern zu können.

Gruß,
Pfeffer.

pfeffer schrieb:

ich sehe nicht, das wir in der Lage sind, 2 Versionen getrennt zu pflegen.

Zum Vergrößern anklicken....

Mit Subversion ist das ja nicht so schwierig: Es werden zwei Entwicklungsstränge angelegt und Fehler in der Bugfixlinie korrigiert. Diese werden per Merge in die NewFeatures-Linie integriert (damit man das nicht zwei mal programmieren muss).
Verlangt natürlich etwas Organisation, was bei vielen dezentralen Hobby-Entwicklern vielleicht etwas schwierig umzusetzen wird.
Und wie Subclipse die Merges handhabt, weiss ich auch nicht... Mit TortoiseSVN geht das recht gut.

Engywuck

Du scheinst zu wissen, wie es geht

Magst Du das vielleicht machen?

Gruß,
Pfeffer.

pfeffer schrieb:

Du scheinst zu wissen, wie es geht
Magst Du das vielleicht machen?

Zum Vergrößern anklicken....

Was meinst Du jetzt mit das ?

die Änderungen, die im Zweig der neuen Features gemacht werden, in die 1.0 einzuspielen.

Gruß,
Pfeffer.

Wir haben das bei 0.9n ja auch schon so gemacht, dass es dafür einen Branch gab. Aber irgendwann wurden die Änderungen zu viel, so dass dort nicht weitergearbeitet wurde. Ein Problem dabei war auch, dass sich keiner mehr für die stable Releases verantwortlich fühlte.

Ich denke schon, dass wir auch für die 1.0 wieder einen Bugfix-Branch anlegen werden. Wie lange und wie oft daraus dann aber neue Stables generiert werden, wird die Motivation der Entwickler zeigen.

pfeffer schrieb:

die Änderungen, die im Zweig der neuen Features gemacht werden, in die 1.0 einzuspielen.

Zum Vergrößern anklicken....

Was man (relativ einfach) machen kann, ist die Änderungen, die in einem Branch gemacht werden, in den andern Branch zu übernehmen.
Wenn ich jetzt mal davon ausgehe, dass Änderungen, die im Bugfix-Branch gemacht werden, auch in den Neue-Version-Branch übernommen werden sollen, so geht das recht einfach, weil ja im Prinzip alle Fehlerausbauten auch in der neuen Version drin sein sollten.
Was nicht zu empfehlen ist, ist, in der Neuen Version weiterzuarbeiten, dort auch Fehler zu fixen, und dann zu erwarten, dass man nur den Fehlerfixanteil in die Fehlerfixversion übernehmen könnte. Denn dann muss man mit sehr viel Sachverstand rangehen und bei jeder Codeänderung prüfen, ob sie jetzt ein Fehlerfix ist oder schon ein neues Feature.

Alles klar?

Engywuck

Ich habe keine Lust, in einer alten Version nach Fehlern zu suchen, die in der neuen evtl. gar nicht mehr drin sind.
Ich werde ausschließlich in der mit Features arbeiten. Aber ich unterstütze Dich gerne beim Rückspielen von Bug fixes in die 1.0.

Gruß,
Pfeffer.

Wie viel Aufwand das Pflegen eines Bugfix-Branches ist, hängt natürlich davon ab, welche Bugfixes man als würdig ansieht, sie in den 1.0-Zweig zu übernehmen. Ich denke, das werden nur Sachen sein, die das Arbeiten mit Cachwolf unmöglich machen. Und das wiederum kann eigentlich nur bei äußeren Änderungen (sprich auf GC-Seite) passieren. Mit etwas Glück ist davon erstmal nur die spider.def betroffen. Wenn auch Codeänderungen notwendig sind, kommt es dann auf den Umfang und die Portierbarkeit an, ob diese in den 1.0-Zweig übertragen werden werden.

Lass uns erstmal die 1.0 stabil herausbringen. Was später passiert wird sich dann schon zeigen.

pfeffer schrieb:

Ich habe keine Lust, in einer alten Version nach Fehlern zu suchen, die in der neuen evtl. gar nicht mehr drin sind.

Zum Vergrößern anklicken....

Du siehst das falsch: Wenn man sich daran gewöhnt, Fehler grundsätzlich in der Fehlerfixversion zu fixen, dann können sie in der Featureversion gar nicht verschwinden, weil man dort eben nur Features einbaut. Wenn man also beim arbeiten mit der Featureversion Fehler zufällig dort findet, müsste man, wenn man sie ausbauen will, sein Fehlerfixprojekt öffnen, den Fehler dort korrigieren - und sobald das nächste mal der Merge von Bugfixversion nach Featureversion gemacht wurde, wäre der Fehlerfix auch dort drin.

Klar, das Verfahren hat Nachteile: Man braucht immer zwei Projekte, an denen man arbeitet; man muss immer aufpassen, in welchem Projekt man grad ist und nicht etwa die Features im Fehlerfixprojekt einbauen, etc., aber richtig sauber gehts im Grunde nur so.

Man kann sich auch auf einen Kompromiss in der Mitte einigen: Fehler und Features werden in einer "Hauptversion" eingebaut, und nur wenn es sich um "dramatische" Fehler handelt (kräftige Speicherlecks, Abstürze, Fehler beim Spidern...), werden diese auch in der Bugfixversion ausgebaut. So dass der Anwender in der Regel auf der Bugfixversion bleiben kann, wenn man an stabilen Versionen interessiert ist.

Wenn man auf diese Trennung ganz verzichtet, wird das früher oder später (mein Tipp: 4-6 Monate) dazu führen, dass es heisst "Nimm nicht die Stable-Version, die ist hoffnungslos veraltet. Probier es mit dem aktuellen Nightly Build." Und damit ist man in der gleichen Lage wie jetzt...

Soviel von der Front der Softwareentwickler ;-)

Engywuck

Engywuck schrieb:

Du siehst das falsch: Wenn man sich daran gewöhnt, Fehler grundsätzlich in der Fehlerfixversion zu fixen, dann können sie in der Featureversion gar nicht verschwinden, weil man dort eben nur Features einbaut.

Zum Vergrößern anklicken....

Es kann aber durchaus sein, dass in der "Featureversion" etwas grundsätzlich anders gelöst wird, um z.B. neue Features zu verwirklichen. Der Code, der in der Bugfixversion einen Fehler verursacht, ist dann in der Featureversion evtl. gar nicht mehr vorhanden.

Engywuck schrieb:

Man kann sich auch auf einen Kompromiss in der Mitte einigen: Fehler und Features werden in einer "Hauptversion" eingebaut, und nur wenn es sich um "dramatische" Fehler handelt (kräftige Speicherlecks, Abstürze, Fehler beim Spidern...), werden diese auch in der Bugfixversion ausgebaut. So dass der Anwender in der Regel auf der Bugfixversion bleiben kann, wenn man an stabilen Versionen interessiert ist.

Zum Vergrößern anklicken....

Das ist genau der Weg, den ich vorgeschlagen habe.