Tolle Neuigkeiten! Wenn Sie eine Abhängigkeit von GitHub hinzufügen, haben Sie jetzt Zugriff auf eine brandneue Regel: 4D Version folgen. Diese leistungsstarke Ergänzung stellt sicher, dass Ihre Abhängigkeiten mühelos mit Ihrer 4D Umgebung synchronisiert werden, wodurch Kompatibilitätsprobleme reduziert werden und Ihr Workflow reibungsloser denn je wird.
VEREINFACHEN SIE IHR ABHÄNGIGKEITSMANAGEMENT
Mit der Regel „Follow 4D version“ müssen Sie nicht mehr manuell verfolgen, welche Versionen von Abhängigkeiten mit Ihrer 4D Version übereinstimmen. Der Dependency Manager übernimmt diese Aufgabe für Sie und stellt sicher, dass die relevantesten und kompatibelsten Versionen automatisch ausgewählt werden. Das bedeutet:
- Weniger manuelle Arbeit: Sie müssen nicht selbst nach den richtigen Versionen suchen.
- Weniger Kompatibilitätsprobleme: Ihre Abhängigkeiten passen immer zu Ihrer 4D Umgebung.
- Mehr Stabilität: Ihr Projekt läuft reibungslos, auch bei Updates oder Downgrades von 4D.
MÜHELOSE UPDATES & ZUVERLÄSSIGE KOMPATIBILITÄT
Wenn Sie Ihre 4D Version aktualisieren, bleiben Ihre Abhängigkeiten gültig, und Sie können ganz einfach die neuesten kompatiblen Versionen abrufen. Wenn Sie ein Downgrade durchführen, passt das System Ihre Abhängigkeiten automatisch an die neue Version an.
KENNZEICHNUNG VON VERÖFFENTLICHUNGEN ZUR AUTOMATISCHEN AUFLÖSUNG
Damit dieses System effektiv funktioniert, müssen die Mitwirkenden sicherstellen, dass die Abhängigkeiten einer strukturierten Tag-Namenskonvention folgen. Der Dependency Manager löst die Abhängigkeiten auf der Grundlage dieser Versionsregeln auf:
LTS-Versionen : Tags müssen dem Muster x.y.p folgen, wobei:
- x steht für die 4D Hauptversion.
- y für die Nebenversion steht.
- p erlaubt Flexibilität für Patch-Versionen oder zusätzliche Updates.
Beispiel: 20.2.3 (Major: 20, Minor: 2, Patch: 3) oder 21.6.1 (Major: 21, Minor: 6, Patch: 1).
Wenn Ihr Projekt angibt, dass es einer 4D LTS Version folgt (z.B. 20.2), wird der Component Manager immer versuchen, die neueste Version der 20.* Serie aufzulösen, wenn diese verfügbar ist. Wenn die gesuchte Version nicht gefunden wird, wird automatisch auf eine frühere Version dieser Serie zurückgegriffen, z.B. 20.1.p oder 20.0.p, wenn diese verfügbar sind.
R-Versionen: Tags müssen dem Muster `xRy.p` folgen, wobei:
- xR entspricht der Hauptversion der Version.
- y steht für die Nebenversion.
- p erlaubt Patches und inkrementelle Aktualisierungen.
Beispiel: 20R3.2 (Major: 20R, Minor: 3, Patch: 2) oder 21R5.1 (Major: 21R, Minor: 5, Patch: 1).
Wenn Ihr Projekt eine R-Version wie 20R3 angibt, versucht der Component Manager zunächst, die neueste Version der 20R3.p-Serie aufzulösen. Wenn diese Version nicht verfügbar ist, wird nach einer Version in der 20R*-Serie gesucht, die kleiner oder gleich 20R3 ist, wie 20R2.p oder 20R1.p.
4DPop- und 4DPop-Macros-Komponenten halten sich bereits an die strukturierten Tagging-Konventionen und gewährleisten eine reibungslose Auflösung von Abhängigkeiten mit der Regel Follow 4D version.
Beachten Sie, dass Sie Ihre Versionsnummer im Titel beibehalten können, wenn Sie Ihre eigenen Komponenten mit benutzerdefinierten Namensregeln haben. Das Tag sollte jedoch strikt dem vorgeschriebenen Format folgen.
KONZENTRIEREN SIE SICH AUF IHREN CODE, NICHT AUF IHRE ABHÄNGIGKEITEN
Mit Follow 4D Version war die Verwaltung von Abhängigkeiten noch nie so einfach. Egal, ob Sie ein Upgrade, Downgrade oder eine Wartung Ihres Projekts durchführen, Sie können sich darauf verlassen, dass Ihre Abhängigkeiten immer mit Ihrer 4D Umgebung übereinstimmen.
Testen Sie es jetzt und erleben Sie eine intelligentere, mühelose Art, Abhängigkeiten zu verwalten!