Technischer Support
Dokumentation
Anmeldung
Kontakt
Gehen Sie direkt zu einer KI-Zusammenfassung dieses Blogbeitrags 
Wichtigste Erkenntnisse
- Die lange Lebensdauer hat das Problem mit dem Lebenszyklus verursacht. jQuery 1.x und 2.x sind nicht mehr unterstützt (EOL) und es gibt keine Upstream-Patches mehr; außerdem weist jede jQuery-Version vor 3.5.0 mindestens eine XSS-CVE auf, die erst in einer späteren Version behoben wurde.
- Die Abhängigkeit taucht in der Regel in Ihrem Abhängigkeitsdiagramm auf. jQuery hat selbst keine Abhängigkeiten, aber Plugins, Themes und Anbieter-Bundles beziehen es in Versionen ein, die Sie nie ausgewählt haben.
- Eine Migration auf eine neue Hauptversion ist kein einfacher Dateiaustausch. Entfernte APIs, Plugin-Fehler und Verhaltensänderungen führen zu Fehlern, die erst bei der tatsächlichen Nutzung durch die Anwender und nicht bereits in der CI zutage treten.
- „Upgrade“ oder „Neuprogrammierung“ ist eine falsche Entweder-oder-Entscheidung. OpenJS betreibt ein nicht-exklusives Programm zur kommerziellen Unterstützung nicht mehr unterstützter Projektversionen, und TuxCare ist einer seiner Partner.
Im Januar 2006 stellte John Resig jQuery auf dem BarCamp in New York City mit einem bescheidenen Ziel vor: das Schreiben von JavaScript weniger mühsam zu machen. Zwanzig Jahre und drei Tage später wurde die Version 4.0.0 veröffentlicht. Irgendwann zwischen diesen beiden Zeitpunkten wurde jQuery 1.11.3 in Ihre Anwendung integriert, und es ist immer noch in dem Paket enthalten, das Sie letzten Dienstag bereitgestellt haben.
Genau diese Lücke ist das eigentliche Problem beim Ende des Lebenszyklus von jQuery. Die Bibliothek selbst ist nicht das Problem. Das Problem ist vielmehr, dass jQuery so früh, so weit verbreitet und so tief in den Code anderer integriert wurde, dass ganze Versionsreihen nicht mehr unterstützt wurden, während sie weiterhin in enormem Umfang in der Produktion liefen. jQuery 1.x und 2.x haben seit 2016 das Ende ihres Lebenszyklus erreicht. Die meisten Websites, auf denen sie laufen, haben davon nichts bemerkt.
Hier ist das Argument, das es wert ist, vorgebracht zu werden, denn es sollte Ihre Abwägung der Optionen verändern: Hier geht es nicht darum, dass Teams nachlässig sind. Es geht darum, dass ein von Freiwilligen gegründetes Projekt die Annahme überdauert hat, dass jeder ein Upgrade durchführt. Die OpenJS Foundation, bei der jQuery heute angesiedelt ist, hat dies öffentlich bestätigt und eigens ein Programm entwickelt, um diesem Problem zu begegnen. Diese Vorgeschichte zeigt Ihnen, welche Ihrer Optionen sinnvoll sind und welche lediglich eine Verzögerungstaktik mit zusätzlichen Schritten darstellen.
Warum das alte jQuery immer noch überall zu finden ist
Um zu verstehen, warum diese Versionen weiterhin bestehen, sollte man sich vor Augen führen, welches Problem mit jQuery ursprünglich gelöst werden sollte. Mitte der 2000er Jahre implementierten die Browser JavaScript und das DOM so unterschiedlich, dass das Auffinden eines Elements, das Anhängen eines Handlers oder das Ausführen einer asynchronen Anfrage browserspezifische Verzweigungen erfordern konnte. Code, der in Firefox funktionierte, schlug im Internet Explorer fehl.
jQuery hat diese Komplexität hinter einer einzigen, übersichtlichen API vereint. Das war nicht nur praktisch. Es bot Teams eine zuverlässige Kompatibilitätsschicht zu einer Zeit, als die Plattform selbst keine bereitstellen konnte, und machte interaktive Frontend-Entwicklung für eine weitaus größere Gruppe von Entwicklern zugänglich.
Jede Produktreihe markiert eine Etappe in dieser Geschichte:
jQuery 1.x (2006) unterstützte Browser bis zurück zu IE 6, was es für Unternehmens- und Behördenanwendungen mit umfangreichen Client-Anforderungen unverzichtbar machte. 1.12.4, veröffentlicht im Mai 2016, war die letzte Version dieser Reihe.
jQuery 2.x (2013) verzichtete zugunsten einer kompakteren Version auf die Unterstützung von IE 6–8, behielt dabei jedoch die gewohnte API bei. Die Version endete mit 2.2.4, ebenfalls im Mai 2016.
jQuery 3.x (2016) wurden die beiden Zweige zusammengeführt. 3.7.1 (August 2023) ist die letzte Feature-Version, und die projektinterne Support-Richtlinie sieht nun vor, dass 3.x nur noch kritische Sicherheitspatches und Fehlerbehebungen erhält, wobei allen Nutzern empfohlen wird, auf 4.x umzusteigen. Die Nutzung von 3.7.1 ist nicht gleichbedeutend mit der Nutzung eines vollständig unterstützten Zweigs.
jQuery 4.0.0 wurde am 17. Januar 2026 veröffentlicht und ist die erste größere Version seit fast einem Jahrzehnt. Sie unterstützt IE 10 und ältere Versionen nicht mehr, wobei die Entfernung von IE 11 für Version 5.0 geplant ist, bietet nun Unterstützung für „Trusted Types“ und konvertiert domänenübergreifende JSON-Anfragen nicht mehr stillschweigend in JSONP. Die beiden letztgenannten Punkte stellen echte Sicherheitsverbesserungen dar.
Was viele Teams übersehen: jQuery UI, jQuery Mobile und Sizzle sind mittlerweile Emeritus-Projekte bei OpenJS, was bedeutet, dass sie offiziell eingestellt wurden. Falls Ihr Migrationsplan den Punkt „und jQuery UI aktualisieren“ enthält, gibt es am anderen Ende keine unterstützte Version mehr.
Was sich am Lebensende tatsächlich ändert
Wenn die Wartungsarbeiten auf der Server-Seite abgeschlossen sind, funktioniert alles wie gewohnt. Formulare werden übermittelt. Menüs lassen sich öffnen. Ajax läuft. Die Anwendung verhält sich genau so wie am Tag zuvor.
Was sich ändert, ist das Sicherheitsmodell. Es wird nicht mehr erwartet, dass das Projekt Korrekturen für diese Version bereitstellt, sodass die nächste Sicherheitslücke, die Ihre Version betrifft, ohne einen entsprechenden Upstream-Patch auftritt. Sie erfahren davon über einen Scanner und nicht über eine Versionsanmerkung.
Eine ausführlichere Aufschlüsselung gängiger Sicherheitsrisiken und CVEs finden Sie in unserem ausführlichen Leitfaden zu jQuery-Sicherheitslücken.
Die CVE-Historie konzentriert sich genau auf die Funktionen, für die jQuery genutzt wird:
CVE-2020-11023: XSS in HTML parsing. Passing HTML containing <option> elements from an untrusted source into .html(), .append(), or similar can execute untrusted code even after sanitization. Affects 1.0.3 through 3.4.1, fixed in 3.5.0. CISA added it to the Known Exploited Vulnerabilities catalog on January 23, 2025, giving federal civilian agencies until February 13 to remediate. Published CVSS scores for this one range from 6.1 to 6.9 depending on which scoring source you consult, which is a fair reminder that the KEV listing rather than the number is what carries the deadline.
CVE-2020-11022: Eine weitere Schwachstelle in derselben Parsing-Logik mit derselben Split-Bewertung. Betrifft die Versionen 1.2 bis 3.4.1, sodass ihr Bereich etwas später beginnt als der von CVE-2020-11023.
CVE-2019-11358 (CVSS 6.1): Prototyp-Verunreinigung in jQuery.extend(). Ein Angreifer, der Einfluss auf das zusammengeführte Objekt nehmen kann, kann Object.prototype. Betrifft alle Versionen vor 3.4.0, also alle 1.x- und 2.x-Versionen.
CVE-2015-9251: XSS bei der domänenübergreifenden Ajax-Verarbeitung. Senden Sie eine Anfrage ohne dataType senden, und ein böswilliger Server kann mit text/javascriptantworten, das von jQuery ausgeführt wird. Betrifft alle Versionen vor 3.0.0.
CVE-2012-6708 (CVSS 6.1): jQuery(strInput) decides whether input is HTML by looking for < anywhere in the string, which gives an attacker more room to build a payload. Affects versions before 1.9.0.
Um es genau zu sagen: Eine betroffene Version bedeutet nicht automatisch, dass eine Anwendung ausnutzbar ist. Das tatsächliche Risiko hängt davon ab, wie Ihr Code jQuery nutzt, ob nicht vertrauenswürdige Daten den anfälligen Pfad erreichen und welche Ausgleichsmaßnahmen Sie getroffen haben. Was diese CVEs jedoch deutlich machen, ist, dass „die Anwendung funktioniert weiterhin“ und „die Anwendung wird weiterhin sicher gewartet“ zwei unterschiedliche Aussagen sind.
Genau an dieser Stelle kommen Audits ins Spiel. Für eine staatliche Behörde, die ein Genehmigungsportal auf Version 1.11.3 betreibt, bedeutet dies in der Praxis nicht, dass es zu einer dramatischen Sicherheitsverletzung kommt. Es handelt sich vielmehr um eine in der KEV-Liste aufgeführte CVE mit einer bundesweiten Frist, einen Befund gemäß PCI DSS 6.3.3, falls Zahlungen beteiligt sind, und einen Prüfer, der nach Ihrem Plan zur Behebung des Problems fragt. Die Aussage „Upstream hat die Patches eingestellt“ reicht nicht aus, um einen Befund zu schließen.
Die Exposition befindet sich in Ihrem Abhängigkeitsgraphen
jQuery ist in sich geschlossen und hat keine Laufzeitabhängigkeiten, wodurch es einfacher ist als die meisten modernen Pakete.
Drehen Sie das um, und Sie erkennen das Problem. jQuery ist eine der am häufigsten genutzten Bibliotheken in der Geschichte des Internets, und Ihr eigener Code macht nur einen kleinen Teil des Gesamtbildes aus. Der Rest besteht aus Plugins, die eine bestimmte Hauptversion voraussetzen, WordPress-Themes, UI-Widgets, kommerziellen Komponenten, die niemand mehr pflegt, Skripten von Anbietern sowie älteren CMS- oder E-Commerce-Plattformen.
Ein häufiges Szenario: Ein Team hat seinen eigenen Code schon vor Jahren von jQuery migriert, alle gehen davon aus, dass jQuery nicht mehr verwendet wird – und dann öffnet man in der Produktionsumgebung den Netzwerk-Tab und stellt fest, dass Version 1.11.3 von einem Pfad geladen wird, den niemand kennt, weil ein lizenziertes Berichts-Widget eine eigene Kopie bündelt. Zwei Versionen auf der Seite, eine davon nicht mehr unterstützt, und keine davon in der „package.json“ enthalten, die jemand überprüft. In manchen Umgebungen wurde die Datei vor Jahren in den Quellcode-Baum kopiert und wird überhaupt nicht von einem Paketmanager verwaltet.
Scanner werden viele davon finden. Die Bibliothek zu finden, ist der einfache Teil. Das Team muss noch herausfinden, warum diese Version vorhanden ist, was davon abhängt und ob sich das Verhalten ändert, wenn sie ersetzt wird.
Genau diese Grafik macht das Upgrade so schwierig. Plugin A ist für Version 1.x vorgesehen. Plugin B ruft .live()auf, das in Version 1.9 entfernt wurde. Plugin C ist eine kommerzielle Komponente, deren Anbieter den Vertrieb 2019 eingestellt hat und deren Lizenz keinen Quellcode umfasst.
Warum OpenJS dafür ein Programm entwickelt hat
jQuery ist ein „Impact Project“ der OpenJS Foundation, der herstellerneutralen Organisation, bei der es nach einem langen Weg der organisatorischen Weiterentwicklung gelandet ist: 2009 bei der Software Freedom Conservancy, 2012 bei der jQuery Foundation und schließlich 2019 durch den Zusammenschluss mit der Node.js Foundation, aus dem OpenJS hervorging.
Die Stiftung beschäftigt sich bereits seit Jahren mit dem jQuery-Sicherheitsproblem. Das Alpha-Omega-Projekt von OpenSSF stellte im Jahr 2022 350.000 US-Dollar bereit, um Sicherheitsvorfälle bei jQuery durch die Modernisierung sowohl des Codes als auch der Nutzer zu reduzieren. OpenJS verlegte das jQuery-CDN zu Fastly, das Ende 2024 monatlich rund 70 Milliarden Anfragen dafür bediente. Die Stiftung entwickelte den „Healthy Web Checkup“, ein Tool, das in fünf Sekunden anzeigt, welche jQuery-Version Ihre Website lädt. Sie gab die IDC-Studie in Auftrag, auf der ihre eigene Schätzung basiert, wonach von rund 1,9 Milliarden Websites fast 90 % jQuery verwenden und etwa ein Drittel davon ein Upgrade benötigt.
Was diese Finanzierung jedoch nicht abdeckt, ist die unbefristete Weiterentwicklung von jQuery 1.8.2. Es gibt eine klare Grenze dafür, wie viel unbezahlte Arbeitszeit der Betreuer für die Fehlerbehebung bei Versionen aufwenden können, die zu einer Zeit veröffentlicht wurden, als Windows 7 noch aktuell war – und wenn man so tut, als wäre das nicht der Fall, führt das dazu, dass die Betreuer ausbrennen.
Um diese Lücke zu schließen, hat OpenJS im Mai 2024 das „Ecosystem Sustainability Program“ ins Leben gerufen. Die Partner stellen kommerzielle Sicherheitspatches für von OpenJS gehostete Projekte bereit, bei denen es sich um archivierte, nicht mehr unterstützte oder ältere Versionen aktueller Projekte handelt, und ein Teil dieser Unternehmensumsätze fließt an die teilnehmenden Projekte zurück. HeroDevs war der erste Partner, gefolgt von NodeSource, und TuxCare trat der Stiftung als Gold-Mitglied und ist nun auf der OpenJS-Partnerseite unter den ESP-Partnern aufgeführt.
Es ist anzumerken, dass das jQuery-Projekt selbst dies als legitimen Weg betrachtet. Seine Richtlinie zur Versionsunterstützung bietet drei Optionen für alle, die eine ältere Version nutzen: ein Upgrade durchführen, die alte Version beibehalten und Sicherheitspatches über kommerziellen Support beziehen oder die Version ohne jegliche Patches weiterverwenden – was das Projekt jedoch als echtes Risiko einstuft.
Die Grenzen spielen nach wie vor eine Rolle, da das Marketing der Anbieter dazu neigt, sie zu verwischen:
- Das Programm ist nicht exklusiv. OpenJS schreibt Ihnen nicht vor, bei welchem Anbieter Sie kaufen sollen, und derzeit sind drei Anbieter auf der „Foundation“-Ebene gelistet.
- ESP-Partner müssen Gold- oder Platin-Mitglieder sein und über eine Markenlizenz für gemeinsames Marketing verfügen, gegebenenfalls mit einer Zustimmung auf Projektebene durch das zuständige TSC oder Kernteam. Eine Partnerschaft auf Foundation-Ebene und die Liste der zugelassenen Anbieter für ein bestimmtes Projekt sind zwei verschiedene Dinge. Überprüfen Sie daher die Projektseite des jeweiligen Projekts, das Sie tatsächlich durchführen.
- Ein Partner-Patch für jQuery 1.12.4 ist ein Patch dieses Partners. Es handelt sich nicht um eine Upstream-Version, und dadurch wird eine alte Version nicht wieder offiziell unterstützt.
- Das Programm schränkt die Betreuer ausdrücklich nicht darin ein, jede beliebige Version ihrer Wahl öffentlich zu unterstützen.
Die jQuery-Betreuer sind für das Projekt und dessen aktuelle Versionen verantwortlich. OpenJS bietet eine neutrale Plattform. Anbieter von erweiterten Supportleistungen übernehmen den Support für bestimmte ältere Versionen, nachdem der Support durch die Entwickler beendet wurde. Dies ist eine nachhaltigere Aufteilung, als von Freiwilligen zu erwarten, dass sie jede historische Version auf Dauer pflegen, oder von jeder Organisation zu erwarten, dass sie eine komplexe Migration genau in dem Moment abschließt, in dem eine Supportgrenze überschritten wird.
Ihre drei Optionen
Auf eine unterstützte Version aktualisieren
Soweit dies machbar ist, ist dies langfristig die richtige Lösung. Die aktuelle jQuery-Version ist besser, und die Unterstützung von „Trusted Types“ sowie die JSONP-Änderung in Version 4.0 verringern aktiv Ihre XSS-Angriffsfläche.
Ein Sprung von 1.x ist jedoch kein Versionssprung. Das Ereignissystem wurde neu geschrieben. Ajax und Deferreds wurden geändert. .bind(), .delegate(), .live()und .error() sind weggefallen oder haben sich geändert. Die Randfälle bei den Selektoren haben sich verschoben. Das jQuery-Migrate-Plugin deckt einen Großteil des veralteten Verhaltens auf und ist daher das erste Werkzeug, auf das Sie zurückgreifen sollten. Es gibt jedoch keinen Hinweis darauf, für welche Ihrer Plugins es keinen weitergepflegten Nachfolger gibt.
Für ein 40-köpfiges SaaS-Team mit einer App, aktuellen Plugins und einer realistischen Testabdeckung sind das ein paar Sprints. Für die interne Verwaltungssuite einer Bank mit insgesamt 200 Plugins und Kundenanforderungen, in denen immer noch der Internet Explorer 11 erwähnt wird, sind es Monate – und die Fehler, die dabei übersehen werden, sind interaktionsabhängige Fehler, die erst in der Produktionsumgebung auftreten.
jQuery vollständig entfernen
querySelector(), fetch(), addEventListener()und classList decken den Großteil dessen ab, wofür Teams jQuery tatsächlich nutzen. Wenn Ihre Nutzung gering ist, ist der Verzicht auf die Abhängigkeit die sauberste Lösung, und dies schrittweise zu tun, ist besser als eine vollständige Neuprogrammierung.
Wenn es nicht schlank ist, sollten Sie den Preis ehrlich ansetzen. Sie schreiben jede DOM-Operation neu, implementieren Hilfsfunktionen neu, verzichten auf die Normalisierungsschicht von jQuery und lassen das alte System parallel laufen, während Sie das neue entwickeln.
Erweiterter Support während der Modernisierung
Manche Anwendungen lassen sich nicht innerhalb des durch eine Offenlegungspflicht vorgegebenen Zeitrahmens aktualisieren, dürfen aber auch nicht ohne Wartung bleiben. Der „Endless Lifecycle Support“ von TuxCare für jQuery umfasst nicht mehr unterstützte Versionen einschließlich 1.8.2, 1.11.3, 1.12.4, 2.2.4, 3.1.1, 3.2.1, 3.3.1, 3.4.1, die über npm bereitgestellt werden.
Es geht nicht darum, Sie auf einer alten Version zu halten. Vielmehr soll die Sicherheitsfrist von der Migrationsfrist getrennt werden.
Drei Fragen klären die Sache in der Regel:
- Ein übersichtlicher Abhängigkeitsgraph, echte Testabdeckung, keine veralteten kommerziellen Plugins? Aktualisieren Sie auf 4.0.0 und die Sache ist erledigt.
- jQuery führt nur $() und .on() in einer Handvoll Dateien verwendet? Dann entfernen Sie es. Bezahlen Sie nicht für den Support von Code, den Sie nicht benötigen.
- Nicht mehr gepflegte Plugins, die Vorgabe, einen Browser auf einem bestimmten Stand einzufrieren, oder eine Migration, die realistisch gesehen erst in zwei Quartalen ansteht? Verlängern Sie den Support und planen Sie das Upgrade sorgfältig.
Was es kostet, wenn man es überstürzt
Wenn eine KEV-Listung oder ein fehlgeschlagenes Audit eine umfangreiche Migration in einen unrealistischen Zeitrahmen zwängt, sind die möglichen Fehlerquellen so vorhersehbar, dass man sie im Voraus benennen kann.
Zuerst kommt der Supportaufwand: Formulare, die nicht abgeschickt werden, Dropdown-Menüs, die sich nicht öffnen lassen, Ajax-Funktionen, die stillschweigend fehlschlagen – vieles davon lässt sich eher auf Verhaltensunterschiede zwischen den Versionen zurückführen als auf etwas in Ihrem Diff. Dann folgt die Stabilität, meist ein Randfall bei einem Plugin, der nur unter Produktionsbedingungen bei gleichzeitiger Nutzung auftritt. Und schließlich die technische Verschuldung, denn unter Termindruck wird das Refactoring aufgeschoben, und „das bringen wir im nächsten Quartal in Ordnung“ wird zur Dauerlösung. Dann das Budget: Stunden von freiberuflichen Mitarbeitern, verzögerte Roadmap und Ihre besten Frontend-Entwickler, die Wochen mit Kompatibilitätsarbeiten verbringen.
Geplante Upgrades sind gut. Panikgetriebene Upgrades sind jedoch eine ganz andere Angelegenheit mit einer anderen Kostenstruktur, und Teams unterschätzen deren Kosten regelmäßig um den Faktor zwei oder mehr.
Wie TuxCare das EOL-jQuery patcht
Erweiterter Support bedeutet mehr als nur die Neuveröffentlichung eines alten Pakets – der schwierige Teil ist das Backporting selbst. Ein Fix, der für einen aktuellen Zweig geschrieben wurde, hängt oft von späteren Umstrukturierungen, anderen Tests oder Browser-Annahmen ab, die in der Zielversion nicht vorhanden sind. Der Patch muss die Sicherheitsabsicht der Upstream-Änderung beibehalten, ohne dabei irrelevantes Verhalten mitzubringen oder die Kompatibilität zu beeinträchtigen, die Sie dazu veranlasst hat, bei der alten Version zu bleiben.
Überwachung und Analyse. TuxCare verfolgt NVD, Herstellerhinweise, GitHub-Sicherheitsfeeds und den KEV-Katalog der CISA und ermittelt anschließend, ob ein gemeldetes Problem tatsächlich eine der abgedeckten Versionen betrifft. Die veröffentlichten Versionsbereiche allein reichen nicht aus; der anfällige Codepfad muss überprüft werden.
Backporting und Validierung. Upstream-Korrekturen werden mithilfe automatisierter Tools an die ältere Codebasis angepasst, wobei Sicherheitsingenieure das Ergebnis validieren; anschließend werden Integrität, Funktionalität und Regression vor der Veröffentlichung getestet. Die Pakete werden signiert und aus den von TuxCare gehosteten Repositories bereitgestellt. Wenn Sie sich eher für die technischen Details als für die Zusammenfassung interessieren, finden Sie weitere Informationen im technischen Whitepaper von TuxCare zum Open-Source-Patching-Prozess ist lesbarer als die meisten Dokumente dieser Art.
Dokumentation. In jeder Version wird festgehalten, welche CVEs behoben und welche Komponenten geändert wurden, einschließlich SBOM- und VEX-Kontext, sodass Sie nachweisen können, welche Befunde bereits behoben sind. Das ist genau das, was ein Prüfer erwartet, und genau das macht den Unterschied zwischen einem abgeschlossenen und einem offenen Befund aus.
Zum Vergleich: TuxCare hat in rund 15 Jahren mehr als 220.000 Patches bereitgestellt und mehr als 5.000 CVEs in Betriebssystemen, Laufzeitumgebungen, Bibliotheken und Anwendungen behoben.
Beginnen Sie mit einer Bestandsaufnahme
Bevor Sie eine Option in Betracht ziehen, sollten Sie herausfinden, was tatsächlich bei Ihnen läuft. Überprüfen Sie Quellcode-Verzeichnisse, kompilierte Bundles, Paket-Manifeste, CDN-Verweise, CMS-Plugins, Anbieter-Bibliotheken und gerenderte Produktionsseiten. Gehen Sie nicht davon aus, dass die von Ihrer Anwendung angegebene Version die einzige ist, die die Nutzer erreicht.
Halten Sie für jede Instanz die genaue Version fest, die Komponente, die sie nutzt, ob sie direkt oder über ein anderes Produkt geladen wird, was davon abhängt, welche Kundenumgebungen weiterhin funktionieren müssen und wie viel Regressionstests eine Änderung erfordern würde. Sobald diese Informationen vorliegen, lassen sich einfache Upgrades klar von risikoreichen unterscheiden.
Überprüfen Sie anschließend mithilfe des Live-CVE-Tracker, der auflistet, was bereits gepatcht wurde. Informationen zu unterstützten Versionen, Preisen und Implementierungsdetails finden Sie unter TuxCares Seite „Endless Lifecycle Support for jQuery“ von TuxCare.
Das nächste Kapitel
Die Beständigkeit von jQuery ist kein Beweis dafür, dass eine Bibliothek ihre Zeit überlebt hat. Sie ist vielmehr ein Beweis dafür, wie umfassend sie ein grundlegendes Problem gelöst hat – bis zu dem Punkt, an dem die Plattform schließlich einen Großteil ihrer Funktionen übernommen hat. Die Version 4.0.0 zeigt, dass das Projekt weiterhin voranschreitet.
In früheren Phasen dieser Entwicklung wurden jedoch Millionen von Zeilen Produktionscode geschrieben, und diese entwickeln sich mit unterschiedlicher Geschwindigkeit weiter. Einige können noch in diesem Quartal aktualisiert werden. Andere sind an geschäftskritische Anwendungen, veraltete Plugins, Kiosk- und Embedded-Browser oder Modernisierungsprogramme gebunden, deren Umsetzung sich über Jahre erstreckt.
Wechseln Sie, wann immer möglich, zu unterstützter Software. Wenn dies nicht sofort möglich ist, sollten Sie genau wissen, welche Versionen Sie verwenden, und einen konkreten Wartungsplan dafür aufstellen. Das „Ecosystem Sustainability Program“ wurde ins Leben gerufen, damit dieser Plan nicht bedeutet, dass Freiwillige auf unbestimmte Zeit Patches für Versionen aus dem Jahr 2016 bereitstellen müssen.
Besuchen Sie TuxCare’s Endless Lifecycle Support für Open-Source-Software und erfahren Sie, wie der erweiterte Support den Rest Ihres Open-Source-Stacks so lange abdecken kann, wie Sie ihn benötigen.
