Ich denke, wenn die Tags aufgeräumt werden, haben wir schonmal bessere Übersicht. Tagging liegt aber AFAIK in der Hand der Developer, und da werden leider viele Tags sinnlos vergeben. Tags sollen der Einordnung dienen und somit (ver)allgemeine(rte) Begriffe sein ("Schlagwort").
Gibt es eigentlich einen "Quality Check" für das Repository? Sprich, dass es jemanden gibt, der auf sinnvolles Tagging, Versionierung, aussagekräftige Changelogs und Feature-Beschreibungen, Stabilität (versus Stabilitätsbezeichnung – sind alle stable wirklich stable?), etc. achtet? Ich denke, dass in der Community einige das ehrenamtlich übernehmen würden (ich könnte / würde z. B. die Tags gerne sichten). [werbewirksame Überschrift dazu: TYPOlight Qualitätsoffensive :P ] (siehe auch Anmerkung [1])
Was mich zu meinem nächsten Kritikpunkt am Repository bringt: Ständig heißt es Update, dabei wurde nur die Buildnummer um eins erhöht und keine Dateien verändert (ok, das soll mit dem neuen Release-Zyklus ja der Vergangenheit angehören). Aber: Es kommt auch öfter vor, dass Dateien geändert oder sogar hinzugefügt werden, dabei aber trotzdem nur die Buildnummer verändert wird! Klar, jeder Entwickler hat seine eigene Art Versionen zu verwalten. Aber ich denke, dass eine einheitliche Regelung (bzw. Richtlinien) der Versionierung förderlich wäre – da es alles um eine Plattform (nämlich TYPOlight) geht und von einer Plattform (Repository) ausgeht. Somit sollte eine gemeinsame Grundlage gegeben sein, auf die sich die Entwickler und – vor allem – die Benutzer beziehen können. Auch verhindern wir damit mindestens teilweise "Wildwuchs", wie es bei vielen anderen CMS leider bei den Erweiterungen passiert ist. (siehe Anmerkung [2])
Was haltet ihr davon?
@do_while: BackupDB ist für mich auch kein (richtiger) Tag – besser wären: backup, sicherung, datenbank, database
[1] "Reviewer" bräuchten Zugriff auf alle Informationen, die über die Zeit für eine Erweiterung gespeichert wurden. Sie müssen nicht zwangsläufig die Rechte haben, Änderungen selbst einzutragen und speichern zu können, aber sollen Verbesserungsvorschläge machen und Erweiterungen / Versionen als "gesichtet" (bez. Tags z. B.) markieren können.
[2] Orientieren sollten sich die Versionen an der Art, wie die Versionen von TYPOlight geregelt sind. Sprich: Der letzte Versionsbestandteil fliegt raus (3 statt wie bisher 4 Teile). Major Updates (1. Teil) bei großen Änderungen, Minors (2. Teil) bei kleinen bis mittleren Änderungen, Builds (3. Teil) für Bugfixes und evtl. (kleinere) neue Funktionen / kleinere Änderungen, die an der "API" nichts ändern. Die Versionierung soll aber (natürlich) weiter im Ermessen des Entwicklers liegen – es soll nicht darum gestritten werden, was eine kleine oder mittlere Änderung ist! Aber der Grundrahmen sollte zumindest stehen.
P.S.: Nicht, dass ich das Repository oder die Erweiterungen schlecht machen will – ich finde das alles prima und eine herausragende Leistung aller Beteiligten! Mir fehlt nur ein wenig die Ordnung
.
Zitieren
Zitat von Psi
Lesezeichen