Naja das Problem ist da halt schon, dass man gewisse Bugs erst bemerkt, wenn man die neue Version produktiv ausrollt. Und ausser grosse Konzerne haben wohl die wenigsten Leute und Firmen, eine vollwertige Testumgebung, die wirklich 1:1 Prod entspricht, und selbst da ist es nicht immer möglich alles abzufangen. Gewisse Dinge bemerkt man nunmal erst wenn es produktiv läuft.
Ich selbst, teste z.B. neue Versionen schon, naja sagen wir ich installiere sie in einer separten VM, aber ich habe jetzt. z.B. nicht mein Handy und PC damit verbunden, und stelle alles 1:1 nach was ich mit meiner produktiven Instanz anstelle. Ich klicke also ein wenig darin rum, und wenn es nicht offensichtliche Bugs im UI sind, oder Apps nach dem Update dekativiert wurden weil sie noch nicht kompatibel sind, merke ich nicht, ob sich irgendwo ein Bug versteckt, der relevant werden könnte auf meiner produktien Instanz.
Das wissen natürlich auch die Entwickler und Entwicklerinnen von Nextcloud und deshalb denke ich, wie bereits geschrieben, dass die festen Releasezyklen schon auch notwendig sind, um überhaupt an “Real Life” Bug Reports zu kommen und man somit ganz bewusst in Kauf nimmt, dass Homeuser und kleine Organisationen diese in ihren Prod-Umgebungen installieren, dann auf Probleme stossen und diese Probleme melden.
Und ja wie ich bereits geschrieben habe, finde ich das legitim, denn es ist alles freie Software, und wenn man ein paar Point Releases abwartet, oder sogar immer auf dem zweitneusten Release bleibt, kann man die meisten Bugs auch gut umschiffen.
Trotzdem sollte man vielleicht etwas klarer kommunizieren, und offen sagen, dass die normalen Nextcloud Releases, um es mal auf Linux-Distributionen zu übertragen (ja, ich weiß, solche Vergleiche hinken immer etwas
), eher eine Art Semi-Rolling-Development-Releases darstellen, also eine Art Mischung aus Debain Testing und CentOS Stream, anstatt echte Stable Releases wie Debain Stable, Ubuntu LTS oder RHEL. ![:wink: :wink:](https://help.nextcloud.com/images/emoji/twitter/wink.png?v=12)