nicht alle changesets auch in freetz-1.1

[coolphoenix]

hallo leute,

ich sehe grad, dass z.b. changeset 2170 oder 2169 nur im trunk hinzugefügt wurde und nicht auch im branch 1.1.

sollten "bugfix" nicht in beiden versionen eingepflegt werden?

bzw. währe es nicht sinvoller, einen 1.0 branch aufzumachen und dort nur noch bugfixes einzuspielen (die auch in den trunk eingespielt werden) und im trunk weiter rumzubasteln?

 

[Silent-Tears]

Derweil nciht, weil wir die Fehelr beseitigen werden, das ganze dann mergen und dann wirklich die 10. releasen.

Somit: 1.1 hat derweil keine funktion, bzw. ist "for special purposes".

lg

c

 

[coolphoenix]

ok, soll wohl heißen: ich muss auf neue features warten (oder selbst die files patchen)

mfg

 

[Silent-Tears]

Genau das soll es heissen. feature-Freeze heisst der Spass. Wir beseitigen Fehler, und wenn wir soweit sind, wird released. Und dann wird weiterentwickelt, bzw. Änderungen eingepflegt. Wenn du allerdigns bei der Fehelrbeseitigung helfen möchtest....

 

[cuma]

Îch find das aber auch etwas merkwürdig. Dass in 1.0 keine neuen Features kommen ist ja ok, aber dass in 1.1 nicht alle Fixes kommen versteh ich net

 

[Silent-Tears]

Liegt daran, dass "1.1" nicht von allen Leuten gepflegt wird, da es eben gerade darum geht, die 1.0 fertig zu bekommen. Ich denke, da wird noch ein merge kommen, wenn das Release fertig ist.

Ich persönlich finde es grad mangels Zeit auch reichlich nervig, 2 verschiedenen Repositories zu Pflegen und unterlasse das entsprechend.

Die Bugfixes werden schon noch reinkommen. Spätestens, wenn zum Release der 1.0 noch einmal gemerged wird. Das spart nämlich dann auch das doppelt pflegen.

 

[McNetic]

Ganz genau. Momentan laufen alle Bugfixes im Trunk ab, der auf freetz-1.0 hinsteuert. Sobald das (zumindest nahezu) fertig ist, werden wir den Trunk in einen Branch freetz-1.0 kopieren und dann in einem (relativ unaufwendigen) Schritt die Neuerungen aus freetz-1.1 auf den Trunk mergen, um dort die Entwicklung weiterzuführen. Das ist nicht unbedingt die übliche Vorgehensweise, aber im Sinne einer möglichst schnellen Release und einem möglichst wenig aufwendigen Merge in diesem Falle von Vorteil.

 

[cuma]

Aha, ich versteh es natürlich besser, wenn ich 2 mal das gleiche erklärt bekomm.

 

[olistudent]

Besser 2x als 0x. ;-)

MfG Oliver

 

[Silent-Tears]

Aha, ich versteh es natürlich besser, wenn ich 2 mal das gleiche erklärt bekomm.

Du kannst ja die Änderungen am Trunk als diff-file jedes mal posten, damit jemand mit Schreibzugriff das jedes mal einpflegen kann, wenn dann Zeit ist.

 

[cuma]

Es is halt nur blöd, dass dann die verschiedenen Revisionen mit den Comments verloren gehen

 

[Silent-Tears]

Dafgür gibt es das Mergen, wenn man es denn nciht so einpflegt, hmm?

 

[cuma]

Hä? Was jetzt, merge oder diff?

 

[Silent-Tears]

Das Mergen kommt später, wenn wir releasen. Diff'en ist grad nciht so relevant, finde ich.
Ich persönlich kümmere mich übrigens gar nciht um die freetz-1.1, egal was da passiert. Erst, wenn die 1.0 fertig ist.