Druckbare Version
Ich will eines meiner Bundles in der nächsten Major-Version so umbauen, daß die Kompatibilität zur aktuellen Major verloren geht. Mache ich dazu im aktuellen Repository einen Branch oder daraus besser ein eigenes Repository? Wahrscheinlich beseitige ich im aktuellen Major noch Fehler oder baue vielleicht sogar neue Funktionen ein. Wird ungefähr so sein, wie bei Contao 4 im Vergleich zu Contao 5.
Ein neues Repository würde ich nicht machen. Selbst einen neuen Branch brauchst du nicht unbedingt. Wichtig ist nur, dass deine Änderungen als neuer Major Release getagged werden, vorausgesetzt du willst dich an Semantic Versioning halten.
Einen eigenen Branch kannst du von dem Stand vor der Umstellung machen - aber das kannst du auch später jederzeit (bspw. wenn du Bugfixes für die alte Version machen willst).
Wenn ich keinen Branch anlege und kein zweites Repository, dann werden doch beim Hin- und Herspringen (Auschecken in Sourcetree?) zwischen den Versionen ("mach Version 1.x zur aktuellen bzw. Version 2.x") ständig die Dateien verändert?! Und da ich nicht innerhalb des Repositorys entwickle, sondern extern in einem normalen (Server-)Ordner, den ich später mit dem Repository synchronisiere, würde ich auch meinen (Server-)Ordner immer wieder (vor und nach dem Coden) an das Repository angleichen müssen.
Zum Glück habe ich derzeit nicht vor, die Version 1.x weiterzuentwickeln oder zu bugfixen. Von daher macht es Sinn, den von Dir vorgeschlagenen Weg mit Entwickeln der Version 2 im Master-Branch fortzusetzen. Ich muß dann nur im Liveweb die Version 1 festtackern, damit ich nicht versehentlich auf Version 2 update.
Ich verstehe leider nicht wie du das meinst.Zitat:
Zitat von Samson1964
Wenn du bei den requirements ^1.0 eingetragen hast, wird ohnehin nicht auf 2.x aktualisiert.Zitat:
Zitat von Samson1964
Ich habe mir am Freitag ein paar Git-Tutorials angeschaut. Wenn man zu einer alten Version zurückspringt und daran arbeitet, werden die Dateien im Repo entsprechend geändert, so daß alle nachfolgenden Versionen erstmal "weg" sind. Beispiel: Eine Datei "info.txt", die in Version 1.2.1 angelegt wird, existiert in Version 1.2.0 nicht. Springe ich zu Version 1.2.0 zurück, wird info.txt im Repo gelöscht. Gehe ich wieder zurück zu Version 1.2.1 wird info.txt wiederhergestellt. Unklar ist mir noch, wie ich in Sourcetree zu einer Version springe (z.B. 1.0.0), um daran weiterzuarbeiten. Und später springe ich wieder zu einer anderen Version (z.B. 1.3.0).Zitat:
Zitat von Spooky
Konkret ist meine aktuelle Version 1.3.3. Nun erstelle ich eine Version 2.0.0, die nicht mehr komplett kompatibel mit Version 1.3.3 ist. An Version 2 entwickle ich nun weiter. Doch irgendwann fällt mir ein schwerer Fehler in 1.3.3 auf und ich muß an der alten Version weiterarbeiten und erstelle eine 1.3.4. Ich hoffe das würde klappen und die 2.x nicht beeinflussen.
In Sourcetree springe ich also hin und her: 1.3.3, 2.0.0+, wieder 1.3.3 mit Nachfolger 1.3.4, wieder 2.x. Dabei aktualisiert Sourcetree ständig das Repo, wenn ich den Tutorials Glauben schenken darf, löscht und ändert Dateien oder stellt sie wieder her.
Genau deshalb kam meine Ausgangsfrage: Branch oder (neues) Repo? Aber wenn das Versions-Hopping beim Programmieren vorzuziehen ist...
Wenn du an der Version 1.x weiter arbeiten musst, dann kannst du ja zum letzten commit oder zum letzten tag dieser Version zurück springen - und davon dann einen Branch machen und den Branch bspw. "1.x" nennen. Den separaten branch kannst du aber auch schon jetzt machen, bevor du mit 2.x anfängst.
Ich lege alte, nicht mehr abwärstkompatible Versionen immer in einen eigenen Branch, darin kann man ja auch neue Versionen taggen falls doch noch ein Bugfix nötig ist.
Zum Beispiel in meinem Visitors Bundle gibt es ein Branch "contao44" und einen Branch "contao49", im Master liegt die derzeitige Entwicklung die erst ab Contao 4.10 freigegeben werden wird.