censhare Upgrades unterliegen einem regelmäßigen Veröffentlichungszyklus. Dies gibt nicht nur unseren Kunden Planungssicherheit für neue Versionen und die Verfügbarkeit von neuen Funktionen, sondern ermöglicht uns eine kohärente und stringente Produktentwicklung.
End of Life / End of Service
Mit der Veröffentlichung neuer Upgrades erreichen alle vorherigen Versionen ihr End of Life (EOL) und es werden keine neuen Funktionen mehr zu älteren Versionen hinzugefügt. Dennoch unterstützen wir alle censhare Kunden, indem wir für alte Versionen vollen Support und Fehlerbehebungen weitere 36 Monate bis zum End of Service (EOS) gewährleisten. Selbstverständlich sind wir unseren Kunden jederzeit bei der Planung und Migration auf eine neuere censhare Version behilflich.
Alle Versionen älter als 2022.1 haben ihr End Of Service Datum bereits erreicht!
End of service 2025
Bitte upgraden Sie auf eine neuere Version im Jahr 2025 um zu vermeiden, dass Sie aus der Gewährleistung ausgeschlossen werden.
September 2025 Version 2022.1.x
Veröffentlicht: September 2022 | End of Life: September 2025
End of service 2026
Bitte upgraden Sie auf eine neuere Version im Jahr 2026 um zu vermeiden, dass Sie aus der Gewährleistung ausgeschlossen werden.
April 2026 Version 2022.2.x
Veröffentlicht: April 2023 | End of Life: April 2026
Oktober 2026 Version 2023.1.x
Veröffentlicht: Oktober 2023 | End of Life: Oktober 2026
End of service 2027
Bitte upgraden Sie auf eine neuere Version im Jahr 2027 um zu vermeiden, dass Sie aus der Gewährleistung ausgeschlossen werden.
Mai 2027 Version 2024.1.x
Veröffentlicht: Mai 2024 | End of Life: Oktober 2027
Support für eine Version, die das End of Service Datum erreicht hat
Mit dem Service Level Agreement (SLA) stimmt der Kunde unserem Produktlebenszyklus und damit dem "End of Service" zu. Erreicht eine Version den Status "End of Service", hat dies folgende Konsequenzen für den Support:
Das SLA ist weiterhin gültig und wir sind verpflichtet, die Verfügbarkeit und Reaktionszeit zu gewährleisten.
Wir sind weiterhin bestrebt, den Kunden zufriedenstellend zu unterstützen.
Für diese Version werden keine Bugfixes mehr erstellt.
Ein einfacher Workaround, wie z.B. ein Neustart des Systems, ist als endgültige Lösung zu akzeptieren.
Es ist auch möglich, dass weder eine Lösung noch ein Workaround bereitgestellt werden kann.
Es können keine speziellen Bereitschaften wie z.B an Wochenenden oder Feiertagen mehr garantiert werden.
Wir sind berechtigt unseren Aufwand in Rechnung zu stellen.
Produkt Release Zyklus
Freigegebene Version (Upgrade Versionen)
Upgrades können wesentliche Leistungsverbesserungen, Veränderung der Softwarearchitektur und/oder neue Funktionalitäten enthalten und erscheinen regelmäßig. Ein Upgrade ändert die zweite Ziffer der Versionsnummer der lizenzierten Software (z.B. 2021.1 auf 2021.2). Beim ersten Upgrade nach dem Jahreswechsel ändert sich auch die erste Ziffer der Versionsnummer (z.B. 2021.2 in 2022.1).
Versionierungsschema: Jahreszahl + Fortlaufende Nummer für jedes Release
Release Candidates (Interne Releases)
Ein Release Candidate ist eine Betaversion eines öffentlichen Releases/einer Upgrade-Version und dient nur zu internen Testzwecken.
Revisionsversionen (Update Versionen)
Revisionsversionen werden nach Bedarf bereitgestellt. Updates liefern Fehlerbehebungen ("Bugfixes") und kleinere Verbesserungen der lizenzierten Software und werden bei Bedarf veröffentlicht. Ein Update ändert die dritte Stelle der Versionsnummer der lizenzierten Software, z.B. von Version 2021.2.1 auf 2021.2.2.
Versionierungsschema: Jahreszahl + Fortlaufende Nummer für jedes Release + Fortlaufende Nummer der Revisionsversion
Wir stellen unseren Kollegen und Partnern alle internen Releases für Beta Tests und zur frühzeitigen Vorbereitung von Kundensystemen zur Verfügung.
Sobald das darauf folgende öffentliche Release veröffentlicht wurde, ist es erforderlich auf die freigegebene Version zu wechseln.
Interne Releases sind nicht für den Einsatz auf Produktivsystemen geeignet.