j-lawyer.org 1.13 ist veröffentlicht – später, und größer als ursprünglich geplant. In der Zukunft sollen Updates in kürzeren Abständen zur Verfügung gestellt werden.
Häufigere Updates haben Vor- und Nachteile: Erweiterungen und Korrekturen kommen schneller zu den Anwendern, können aber eine Hürde für alle jene darstellen, die eher defensiv aktualisieren wollen oder Updates nicht ohne Hilfe installieren möchten.
Daher soll an dieser Stelle mal ein größeres Meinungsbild eingeholt werden: Wie oft möchtet Ihr Updates haben?
(Umfrage geschlossen – Ergebnis mit Stand vom 19.01. anbei)
Vielen Dank für Eure Rückmeldungen.
Aus meiner Sicht ist das ein ausgewogenes Verhältnis von Update-Arbeit zu Update-Vorteil.
Wer Rückmeldungen über die diversen Kanäle (Github, Website, E-Mail usw.) gibt, erhält mit einer höheren Wahrscheinlichkeit eine Reaktion in Form eines Updates. Das wirkt motivierend auf die Mitwirkenden. Es hat zugleich den Effekt, dass bei einer Meldung von Fehlern, bugs, features usw. Jens eine sinnvollere Planung vornehmen kann. So können große Umstellungen vielleicht mutiger angegangen werden, wenn diese nicht zugleich mit anderen großen Umstellungen erfolgen. Ein alle 2 Monate stattfindendes Update kann auch dazu führen, dass die Nutzer die notwendigen Schritte bei einer Aktualisierung nicht bereits vergessen haben, wenn dieses ansteht (das wäre bei mir z.B. bei Updates alle 6 Monate wahrscheinlicher, bisher waren die Update-Zyklen eher bei ca. 5-6 Monaten).
Jeden Monat Updates halte ich allerdings für eine mögliche Überforderung der Nutzer. Wer z.B. urlaubsbedingt ein Update nicht sofort vornehmen kann, steht zu kurz vor dem weiteren Update. Auch stellt es eine mögliche Überforderung unseres genialen Hauptentwicklers dar, der auch mal eine Auszeit braucht.
Moin zusammen,
die Updatefolge von „alle 6 Monate“ halte ich für gerade noch vertretbar kurz. Nach dem in der EDV geltenden Grundsatz „never touch a running machine“ sollte eine funktionierende Version so lange am laufen gehalten werden, bis sie durch eine neue, ihrerseits fehlerfrei laufende Version ersetzt, werden kann. Zwischenupdates (besser Korrekturupdates ohne wesentliche Änderungen) ausgenommen. In zu kurzen Abständen kann das nicht gewährleistet sein.
Ich halte es auch für überflüssig und sogar schädlich, andauernd neue Gimmicks einzuführen, die sich vielleicht nach Monaten/Jahren als ungeeignet herausstellen, mit der Folge, daß zurückgebaut werden muß.
Anders ausgedrückt: Eine neue Version (konkret 1.13) muß sich im ausgiebigem Praxisbetrieb erst einmal bewähren, bevor an Neuerungen gedacht (und abgefragt) werden kann. Da sind imho 6 Monate sehr knapp bemessen.
Ich arbeite mit MX-Linux. Korrekrutupdates erfolgen hier (wie auch bei Debian) sehr häufig. Größere Updates mit wesentlichen Änderungen (Analog JLawyer 1.12 zu 1.13) kaum mal jährlich.
Folglich bin ich für derartige Updates besser einmal im Jahr.
RA Steyer aus Leverkusen
Da es hier in Richtung Fehlerfreiheit / Qualität geht: fehlerfreie Software gibt es tatsächlich nicht. Bei mehreren Hunderttausende Zeilen Code sind Fehler eine statistische Sicherheit.
j-lawyer.org nutzt automatisierte Tests, die regelmäßig ausgeführt werden, sowie manuelle Tests seitens der Entwickler. Zusätzlich gibt es immer die Pilotphase vor einer Veröffentlichung. Und hier sei deutlich formuliert: die Anwender haben die Qualität selbst in der Hand – das beginnt bei detaillierten Beschreibungen von Erweiterungen und dem Rückmelden von Fehlern (=Mitarbeit an den Tickets), Rückmeldungen während der Umsetzung (bspw. via Demosystem) und dem Beteiligen an Tests vor Veröffentlichung.
Der Vergleich mit Debian ist an dieser Stelle nicht ganz passend – Betriebssysteme und Fachsoftware haben unterschiedliche Anforderungen bzgl. funktionaler Erweiterungen und deren Frequenz.
Ich finde, dass Jens für die Update-Frequenz bisher das richtige Gefühl hat. Ich persönlich habe für 3 M. gestimmt, aber auch 6 M. fände ich OK. Und wenn es einmal den absoluten j-lawyer-Knaller in einem Update gäbe, würde ich auch gerne nach 1 M. wieder updaten.
Also erst mal Danke an Jens für die ganze Arbeit die in diesem Projekt steckt. Wer einmal ein bischen programmiert hat, weiss, wieviel Zeit man in ein paar Zeilen Code vergraben kann. Ich finde es kommt auf das Update an. Ein „blöder Bug“ könnte schneller mal upgedatet werden, eine große Änderung sollte nicht dazu führen, dass dahinter ein Updaterückstau entsteht. Das wurde bei der 1.13 ja bzgl. des Konzepts der Buchhaltung auch berücksichtigt. Ein auch nur kleines Update bedeutet aber auch viel Arbeit. Dokumentation ändern, Webeseite ändern, Installationsroutinen überarbeiten. Das ist „undankbare“ Zeit, die nicht zu oft anfallen sollte. Ich würde auch sagen, bei einem kritischen Update ASAP, ansonsten sind 6 Monate gut. BEA gibt eh einen eigenen Takt vor, was die BRAK angeht.
Und wenn die Updates zu kurz aufeinander kommen ist auch der Aufwand fürs updaten in schlechterer Relation zu den Änderungen. 6 Monate wäre toll, einmal im Jahr – ich ertappe mich dann irgendwann nach 9 Monaten dass ich immer öfter schaue, was denn noch offen ist, vor allem wenn ich mich auf spezielle Funktionen schon lange freue (wie hier jetzt die Ordnerstruktur in den Dokumenten z.B.).