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 2019.3 haben ihr End Of Service Datum bereits erreicht!
End of service 2023
Bitte upgraden Sie von den Versionen 2019.3.x bis 2020.2.x auf eine neuere Version im Jahr 2023 um zu vermeiden, dass Sie aus der Gewährleistung ausgeschlossen werden.
20. März 2023 Version 2019.3.x
Veröffentlicht: 22. November 2019 | End of Life: 20. März 2020
7. August 2023 Version 2020.1.x
Veröffentlicht: 20. März 2020 | End of Life: 7. August 2020
16. Oktober 2023 Version 2020.2.x
Veröffentlicht: 7. August 2020 | End of Life: 16. Oktober 2020
End of service 2024
Bitte upgraden Sie von den Versionen 2020.3.x bis 2021.1.x auf eine neuere Version im Jahr 2024 um zu vermeiden, dass Sie aus der Gewährleistung ausgeschlossen werden.
30. Juli 2024 Version 2020.3.x
Veröffentlicht: 12. Januar 2021 | End of Life: 30. Juli 2021
26. November 2024 Version 2021.1.x
Veröffentlicht: 30. Juli 2024 | End of Life: 26. November 2021
End of service 2025
Bitte upgraden Sie von den Versionen 2021.2.x auf eine neuere Version im Jahr 2025 um zu vermeiden, dass Sie aus der Gewährleistung ausgeschlossen werden.
06. September 2025 Version 2021.2.x
Veröffentlicht: 26. November 2021 | End of Life: 06. September 2022
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.