Druckbare Version
TYPOlight Version 2.7.5 ist verfügbar. Das Maintenance-Release behebt das Problem mit der Aktivierung von Newsletter-Abonnements bei der Mitgliederregistrierung und korrigiert die Anzeige mehrmonatiger Events. Wenn Sie das Newsletter- oder Kalendermodul verwenden, sollten Sie das Update einspielen.
Ganzen Beitrag zu 'TYPOlight 2.7.5 verfügbar' lesen
Wow ist das ein kleines Update. Da hatte ja selbst 2.6.6 mehr Tickets :D
Hallo,
nachdem Update musste ich jede Erweiterung reparieren/aktualisieren und mich dann durch die "Bestätigen-Dialoge" klicken. Gibt es eine Möglichkeit das 'in einem Rutsch' zu erledigen?
Lieben Gruß,
Stephan
Hallo Stephan,
sehe das so wie Du. Wäre schön, wenn nach einem (geringfügigen) Update solche Maßnahmen nicht mehr nötig wären. Zumal jetzt für die meisten Meldungen auftaucht: "Nicht erprobt für TYPOlight 2.7.5 stable."
Gruß, Frank
Nanu, den Fall hatte ich ja noch nie.Zitat:
Zitat von StephanP
Was brachte Dich dazu? Stand in der Erweiterungsverwaltung das Du das tun sollst?
Mal abgesehen davon, das es bei jedem Update diese Diskussion gibt, so ist diese Meldung doch völlig in Ordnung.Zitat:
Zitat von frank
Ich könnte wetten, wenn man die letze Stelle der Version in der Überprüfung weglassen würde, käme bei jedem Update die Frage auf, ob denn Extension xy für die neue Version schon getestet wurde.
Mhh... eigentlich sollte man so gesehen die Moeglichkeit schaffen dass user extensions als inkompatibel markieren koennen anstatt dass die Developer immer als kompatibel markieren myssen.Zitat:
Zitat von BugBuster
Sei es nun durch voting oder wer weiss was.
@BugBuster
Die Meldung ist doch völlig in Ordnung. Bitte nicht falsch verstehen! Nichtsdestotrotz muss man alle installierten Erweiterungen derzeit manuell aktualisieren! Bei meinen paar Kunden kann ich damit gut leben. Aber was ist, wenn jemand ein paar hundert Kunden aktualisieren muss?Zitat:
Mal abgesehen davon, das es bei jedem Update diese Diskussion gibt, so ist diese Meldung doch völlig in Ordnung.
Ich könnte wetten, wenn man die letze Stelle der Version in der Überprüfung weglassen würde, käme bei jedem Update die Frage auf, ob denn Extension xy für die neue Version schon getestet wurde.
Gruß, Frank
Die Meldung "nicht erprobt..." finde ich ok, ich seh ja selbst, ob sie läuft oder nicht.
Nur was ich doof finde ist, wenn da steht "aktualisierte Version...", die einzige Aktualisierung aber darin besteht, dass die Versionsnummer angepasst wurde damit die Meldung "nicht erprobt..." nicht mehr kommt (was seltsamerweise teilweise sogar ausblieb).
Bei einem Hinweis "aktualisierte Version..." gehe ich davon aus, dass der Code eine Verbesserung erhalten hat, notwendig ist zur Kompatibilität mit dem neuesten Tl, oder neue Feature hinzugekommen sind. Streng genommen müsste ich mich also vor jedem Ext.Update über die Änderungen informieren, was mit einem großen Aufwand verbunden wäre.
Eine Automatik um alle Erw. upzudaten, nur damit da nicht mehr steht, "akt. Version erh...." wäre somit also irgendwie Blödsinn.
Ich würde mir also wünschen, dass die Entwickler ihre Erweiterungen nur dann aktualisieren, wenn es aus einem der obigen 3 Gründen notwendig ist.
- Code-Optimierung
- Lauffähigkeit mit neuer Tl-Version hergestellt
- neue Feature integriert
Alles andere ist nur unnötiger Aufwand.
Andreas
Den Vorschlag find ich super.Zitat:
Zitat von xtra
wobei ich mir dann vorstellen kann ein User eine Ext als inkompatibel markiert obwohl er/sie nur falsch konfiguriert hat.
HI
es kann ja demokratisch sein: Wenn die Mehrheit ihr OK gibt, wird sie kompatibel. Wobei die Entscheidung eines Entwicklers doch noch eine größere Relevanz haben sollte, also wenn der Entwickler sagt: „Gebe ich frei“, dann darf der Nutzer nicht durch viele irrtümliche Meldungen eine Inkompatibilität deklarieren.
Sebastian
Am sinnvollsten wäre meiner Meinung nach, das der Entwickler einen Build freigeben kann und dann direkt im BE erscheint "aktuell" ohne das jedes Mal ein neues Build ohne Änderungen aktualisiert werden muß.
Dazu müsste der Entwickler aber vor dem "Save" makieren können, "kein neues Build nötig, nur die zip neu packen."
Denn der Vergleich ob was neues da ist geht ja über die Versionsnummer.
Es reicht auch nicht zu sagen, wenn sich nur die XML ändert dann generell kein neues Build. Wenn ich z.B eine Abhängigkeit zu einem weiterem Modul vergessen hatte anzugeben, müsste ich dann extra ne neue Version generieren. Wäre auch nicht optimal.
Nebenbei, die Diskussion gab es schonmal, kann sein das die noch im altem Forum schlummert.
Ein schöner kleiner Workaround wäre einfach, die Buildnummer nicht anzutasten, wenn sich nur die XML-Datei verändert und dabei nur die Maintenance-Version-Abhängigkeit von TL ändert. Klingt zwar nach "dirty", aber das wäre die einfachste Änderung. Alternativ schafft man den Versionsvergleich für Maintenance-Versionsnummern aus, was aber durchaus an manchen Stellen zu Problemen führen könnte (wenn es z. B. wirklich eine Abhängigkeit zu einer bestimmten Maintenance-Version gibt).
Hi.
So wie es ist, ist es korrekt. Wenn TL aktualisiert ist, kann Leo nur dafür stehen. Für die Extentions kann nur der Entwickler derselben stehen.
Es ist erheblich zweckmäßiger, auf eine mögliche Inkompatibilität hinzuweisen, als sich hinterher das Geschrei anhören zu müssen, warum einen keiner gewarnt hat. "Abstimmen" mag zwar demokratisch sein, aber bloß weil bei der Abstimmung ("1 Teilnehmer") "alles ok" ist, ist das noch lange keine Gewähr für "funktioniert unter den vom Entwickler definierten Bedingungen". Und wo müsste denn die Grenze gezogen werden, ab wann ein Abstimmungsergebnis glaubwürdig ist? Bei einem, 10, 100 Teilnehmern? Da würden es manche Extentions womöglich nie schaffen, als kompatibel zu gelten, weil zu wenige sie einsetzen.
Und wem es zuviel ist, seine Extentions mal abzuklappern und zu aktualisieren, der kann ja einen Dienstleister damit beauftragen. Einem Automaten würde ich das ebenfalls nicht anvertrauen (siehe „Geschrei“ oben).
Grüße
NoSi