Druckbare Version
Wie vielleicht einige bemerkt haben, läuft die Entwicklung der nächsten Version des Erweiterungsverzeichnisses oder Extension Repository Version 2 (ER2). Ich werde an dieser Stelle von Zeit zu Zeit aus der Entwicklung berichten.
Ganzen Beitrag zu 'Extension Repository 2 zum Ersten' lesen
Bloses anschauen der Einstellungen erzeugt keinen neuen Build. Ein neuer Build wird erstellt sobald irgend etwas geändert wird das auch eine Änderung im Package bewirkt.
Allerdings könnte man das schon noch reduzieren indem reine Änderungen an technisch unkritischen Elemente wie z.B. description, releasenotes, license oder copyright keinen neuen Build mehr erzeugen. Beim Download eines Packages hat man dann halt in diesen Elementen ggf. noch alte Werte drin.
Welche Elemente würdet ihr sonst noch ausklammern?
Lass es doch den Entwickler entscheiden, so wie er auch das Element bei der Erstellung freischalten muss.
Ich habe es oefters gehabt, das ich Daten haeufiger anpassen muss. und jedesmal kam ein neues Build.
Ich wuerd es mir so wuenschen, das man seine Veraenderungen machen kann, incl. einer "Vorschau", wie es nachher auf der ER Seite angezeigt wird.
Und ich muss explizit den Build freischalten.
So wuerd ich es mir wuenschen.
Und wenn schon ein neuer Build erstellt wird, oder ein neues Release/Paket kommt, das ganze auch via RSS abrufbar. Oder JSON, oder sontigem Request.
Mein rep_notifier fragt naemlich regelmaessig den SOAP Server ab. Mittels statischer Infos (RSS,JSON) waere sowas fuer alle Effizienter.
Habt Ihr/Du das ganze ueber den "internen" Bugtracker am laufen ? Mir gehts um die Features, dann koennte man es dort einfacher alles aufschreiben. Da noch einige Idee vorhanden sind, und dies ueber die "neutrale" Schnittstelle Redmine nutzen.
Ginge dies ?
Manuelle Inkrementierung würde die Implementierung mächtig verkomplizieren. Du musst dir vorstellen, dass sobald du etwas änderst diese Änderung von einem Anwender als "alter Build" installiert würde. Jetzt änderst du nochmal etwas und erzeugst erst dann den neuen Build (oder vergisst ganz den neuen Build zu erzeugen). Die Folge ist, dass je nachdem wann man die Erweiterung installiert hat, der gleiche Build unterschiedliche Dateien enthält. Umgehen liesse sich das nur, indem die gesamte Repository DB (also von allen Tabellen, und das sind einige) aufgeteilt würde in eine Live Version und eine Edit Version, und die Edit Version erst beim neuen Build über die Live Version kopiert würde.
Das ist momentan nicht möglich, dazu müsste die Konfiguration in Redmine geändert werden. Das SVN vom Repository müsste dann irgendwo anders liegen, da 90% des Repository closed Source ist. Ich werde mal mit Leo abklären ob wir das ER-SVN wieder auf meinem Server hosten wollen, dann könnte man den Tracker veröffentlichen.Zitat:
Zitat von lindesbs
Momentan können Repository-spezifische Tickets auch auf contifex.com erstellt werden, siehe Ticket Link in meiner Signatur.
find ich auf jeden Fall super das mit dem neuen ER2, was ich noch gerne wissen würde gibt es dann auch eine Volltext suche?
Ja gibt es, wurde in einem anderen Thread schon bestätigt und ist auch auf der Seite von acenes bereits zu Demozwecken aufgeschaltet :)Zitat:
Zitat von schman
Ja, ist aber noch in Arbeit. Ich werde darüber und über andere Änderungen später berichten.Zitat:
Zitat von schman
Zitat:
Zitat von acenes
Also ich kann in meinen Redmine Installationen (auch tl-forge) jedem Projekt selbst zurordnen, ob ich SVN integriert haben moechte (Angezeigt ueber das WeBFrontend). Und den SVN Zugriff kann man sowieso regeln.
Nu ja, ich nutze exessiv SVN, und dort habe ich meine Arbeitskopie und meien getaggten Versionen. Der Entwickler muss einen Zweig taggen, damit gibt er ja auch die Freigabe fuer "ist getestet und verwertbar".Zitat:
Zitat von acenes
Wenn ich nun meine Arbeiten am Modul habe und mir faellt waehrend des Arbeitens auf, das es noch ein Fehler gibt, weil Dateien ueberschrieben werden, oder fehlerhafter Code hochgeladen wurde, muss ich das im ER berichtigen.
Ist nun gerade ein User in seinem Backend unterwegs und sieht :"Hups neues Update" macht er dieses. Und holt sich evt. eine defekte Version. (dies ist mir schon oefter passiert, und hatte veraergerte NutzerPNs !)
Durch ein Freischalten der hochgeladenenen Daten wuerde das meiner Meinung nach deutlich einfacher werden.
Und ein explizites Freischalten ist ja auch beim erstellen und beim Kopieren von Noeten, da muss die Erweiterung/Sprache auch auch gesondert aktiviert werden.
Wenn mehrere Dateien aufs mal zu ändern sind kann man diese in einem ZIP hochladen. Das geht nicht nur viel schneller und einfacher, es vermeidet auch inkonsitente "Zwischen"-Builds.
Das mache ich ja, aber ich teste danach auch gleich an einer OnlineVersion, ob die hochgeladene Version auch funktioniert. Und da man manchmal auch noch Daten (DebugAusgaben in PHP/JS) vergisst, passiert es halt auch, das man meherere Anlaeufe braucht.
Nun ja, meiner Meinung nach sollte der Entwickler die Moeglichkeit haben, wann er sein Modul freigibt, wann alle Uebersetzung fertig sind, alle Darstellungen im ER usw.
Du/Ihr habt eine andere Meinung.
OK.
Ich habe den Eindruck dass du mit dem ER nicht sonderlich vertraut bist, respektive die Idee dahinter noch nicht verstehst.
Selbverständlich ist jede neue Release zunächst unveröffentlicht, und du als Autor veröffentlichst sie dann wenn du denkst es ist für die Öffenlichkeit bereit. Was wir oben diskutiert haben bezieht sich nur auf neue Builds von bereits veröffentlichten Releases - diese sind primär für Patches gedacht, und nicht wie das offenbar von dir praktiziert wird um neue Versionen hochzuladen.
Ich denke nicht nur "Wir", sondern auch die Anwender gehen eigentlich davon aus dass nur Versionen veröffentlicht werden die fertig und vom Autor getestet sind. Wenn du das anders praktizierst ist es befremdlich das ER für den (IMHO berechtigten) Unmut der Anwender verantwortlich zu machen und, eine exterem aufwändige Softwareänderung am ER zu verlangen die in der Praxis null Wirkung haben würde.
Falls es dir aber darum geht die Installation und den Update zu testen, so kannst du das auf den Test-ER auf contifex.com machen, ohne dass Anwender unfreiwillig zum Versuchskarnikel werden.
Doch ich bin damit vertraut. Manch einer sagt mir nach, das ich die Idee/das Prinzip oftmals nicht verstehe. Aber das sehe ich anders. OK.Zitat:
Zitat von acenes
Es ist vor kurzem erst passiert, das jemand seine Extension geupdatet hat, und diese einfach im falschen Verzeichniss erschien. (TL_ROOT/system anstatt TL_ROOT/system/modules/) Nur so als Randbemerkung.
Das ist mir neu, das man dort einen TestER hat. Hast Du ein paar Informationen dazu ? Kann ich ihn einfach so nutzen ?Zitat:
Zitat von acenes
Ja, du musst dich einfach auf der Site als Mitglied registrieren. (Respektive ein neues Passwort verlangen wenn dein Account schon vorhanden ist)Zitat:
Zitat von lindesbs
Übrigens gibt es auch die Möglichkeit Alfa, Beta und RC Versionen im Live-ER zu veröffentlichen, und die Stable erst dann herauszugeben wenn die neue Release etwas abgehangen und stabilisiert ist. Auch das vermeidet Anwenderfrust und wäre eigentlich das korrekte Vorgehen für nicht-triviale Erweiterungen.
Danke fuer die InfosZitat:
Zitat von acenes
Jepp, das ist mir schon klar, aber dieses Scenario kann ich seltenst nutzen, weil ich zwar auswaehlen kann, ich moechte die alpah/beta oder rc dargestellt haben, waehle mir mein Modul, und bekomme im BE die letzte aktuelle angezeigt !Zitat:
Zitat von acenes
Habe es vor langer Zeit ja so machen wollen, das geht aber nicht. Ich muss erst meine Version deinstallieren, den DB Update uebergehen, mir die Beta heraussuchen aus dem TL-ER und per Hand installieren.
Nachvollziehen kannst Du das selbst ganz einfach : Waehle in deinem BE den Erweiterungskatalog, mache einen Filter auf ein gewuenschtes Modul (z.B. graphicaltext) und waehle als weiteren Filter eine "beta"
Die Beta 0.0.15beta1 wird angezeigt. SUPER !
klicke auf den Link des Moduls, die Modulansicht wird angezeigt. SUPER
Klicke auf den Button "Installieren" --> er will die 0.5.0 stable installieren.
SOmit kann ich nur den Umweg ueber die manuelle DownloadMoeglichkeit und haendische Installation waehlen.
Aber du hast ja gesagt, das es auf contifex den Tracker gibt, ich werde dort einfach meine Dinge berichten.
Und glaube mir : Ich habe mich lange mit dem ER beschaeftigt. Ich habe eine Idee von dem Ding....
Mir gehts doch nur darum, dem Entwickler einfach selbst entscheiden lassen zu koennen, wann er eine Version freigibt.
Ich kann den Text im Frontend des ER anpassen, aber dazu gibt es keinen tinyMCE, also muss man alles per Hand machen. Und sich das Ergebnis im FE anschauen. (Schwupps neues Build)
Viele Updates von Erweiterungen sind unnoetig, weil sich nur die Versionsnummer veraendert, von 2.7.6 auf 2.8.1 Tauglichkeit. Das ist dann aber kein neues Build, weil nicht ausgetauscht/geupdated wird.
Sowas verwirrt viele Nutzer: "Warum muss ich ein Update machen, wenn nichts zum Updaten passiert" : Diese Frage habe ich oftmals per PN oder ICQ bekommen
Und man kann einem Nutzer dann schlecht erklaeren : Weil ich den Text im ER Frontend fuer die Modulbeschreibung geaendert habe; musste ein Komma anders setzen.
In Absprache mit Peter wurde der Repository-Tracker nun veröffentlicht.
http://https://contao.org/projects/repository/
Danke fuers freischalten, nun brauch ich nach meinem Ticket nicht mehr fragen ;-)
Beim Update von Erweiterungen tritt bisweilen das Problem auf, dass bei mehreren installierten Erweiterungen die Abhängigkeiten unübersichtlich werden. Gerade beim Update mehrere voneinander abhängiger Erweiterungen kommt es schnell vor, dass ein Update eingespielt wurde, welches zwar mit der einen aber nicht mit der anderen Erweiterung zusammen passt.
Super wäre es, wenn solche (alle) Abhängigkeiten entweder vor dem Update gecheckt oder aber in der Erweiterungsverwaltung angezeigt werden könnten, sodass man vor dem Update zumindest manuell abklären kann, ob das Update sinnvoll ist.
OK, ich weiß, dass das wahrscheinlich sehr aufwändig ist, aber toll wäre es trotzdem...
...vielen Dank auf jeden Fall schon jetzt für Eure Arbeiten!
In V2 werden nur noch Extension-Updates angezeigt welche zur eigenen TL Version kompatibel sind.Zitat:
Zitat von TLight
Wenn es Abhängigkeiten gibt, darf der Autors seine Extension erst dann als kompatibel kennzeichnen wenn das auch für alle Erweiterungen erfüllt ist von denen seine eigene abhängt.