Interessant sind prinzipiell alle .md Dateien in diesem Ordner:
Anderes eigentlich nicht. Was mich derzeit noch Nerven kostet: das händische Aufbauen der Referenz-Bereiche mit den Podcast-Logos und Links zu deren Projektseiten. Das ist schon wichtig, aber da wäre ein Mechanismus fesch bei dem man nur eine URL eingibt (iTunes? Feed?) und sich das System automagisch das Bild zieht etc.
Das ist einfach und war für später vorgesehen. Der XML Parser ist schon fertig und nehme ich von Podbe.
Eine kleine „inner API“ habe ich für Ultraschall Adminseite erdacht. Die habe ich jedoch noch nicht angefangen, die soll jedoch das „schnelle Updaten“ der Grunddaten ermöglichen.
Ich würde mich jedoch über ein release.json freuen oder so etwas, wo kurz die Daten inne stehen. Vielleicht kann ich das aber auch anderes machen…
{ "version": "20.1", "name": "Grupis", "date": "12-12-20xx", "mac_download_url": "https://....", "win_download_url": "https://....", ... was auch immer automatisch ein update bekommt... }
So das mit dem Markdown dürfte ok gehen. Ich habe gerade ein paar filter gebastelt, die das Design so umsetzen wie ich es schon gebastelt habe.
Ihr habt jedoch zwei unterschiedliche Interpretationen im Markdown genommen um die changes zu schreiben. Ich muss daher die alten changes, der neuen noch anpassen.
Du könntest probieren, die Kategorienüberschriften rechtsbündig zu setzen - die Zuordnung zu den Inhaltsteilen fällt aufgrund der Distanz ein wenig schwer. Aber sieht gut aus.
Dabei musst du aber auf den Branch achten und die Updates immer aus ‘master’ holen. Die restlichen Branches sind nur zur Entwicklung und können merkwürdige Zwischenstände enthalten.
Noch besser wäre es, wenn du auf das entsprechende Release-Tag guckst. Also z.B. auf ‘v2.1’
Ich könnte also noch eine Angabe zu den Tags machen? Dann sollte es recht einfach sein zu wissen was man auf der Seite hat. Vielleicht reicht aber auch einfach der Link…
Du darfst auf keinen Fall auf einen anderen Branch als auf ‘master’ zugreifen. Das hat den ganz praktischen Grund, dass die anderen Branches gelöscht werden, wenn ein neues Release erscheint.
Beispiel: Aktuell gibt es drei Branches: master, 2.1.1 und 2.2. 2.1.1 ist der Branch, auf dem wir die 2.1.1 entwickelt haben. Der Inhalt ist bereits in master eingeflossen und wird demnächst gelöscht. Auf 2.2 findet die Entwicklung der nächsten Version statt. Wenn die nächste Version fertig ist, wird der Inhalt dieses Branches in master gemerged und der 2.2er Branch gelöscht. Dann ziehen wir vom master-Branch einen neuen Branch, auf dem wir die übernächste Version entwickeln. Also wahrscheinlich 2.3 oder 3.0. (Könnte erfahrungsgemäß auch 2.2.1 werden)
Die Pfade werden so bleiben. Sie sind auch in den Build-Scripts hardwired. Du kannst ja mal in Ultraschall\Installer\build.sh reingucken (Zeile 25ff.).