Libelektra: 0.9.4-Version

Erstellt am 8. Nov. 2020  ·  21Kommentare  ·  Quelle: ElektraInitiative/libelektra

Aktualisierung

  • [X] Versionshinweise schreiben
  • [x] führe scripts/dev/update-infos-status mit Argumenten für Heuristiken aus
  • [x] Überprüfen Sie, ob die Website korrekt gerendert wird
  • [x] doc/COMPILE.md aktualisieren, um tatsächlich getestete Setups wiederzugeben #3384
  • [x] Clang-Format-11 #3640

Versionsnummern erhöhen

  • [x] CMakeLists.txt
  • [x] VERSION-Variable im Build-Server ändern

Hilfreichster Kommentar

Scheint, als wäre die Veröffentlichung jetzt fertig :fireworks:

Ich habe auch ganz vergessen, einen Fehlerbericht darüber zu erstellen, wie @markus2330 in #3601 (Kommentar) vorgeschlagen hat. Werde das in den nächsten Tagen machen. Alles auf mehrere PRs verteilt zu haben, verwirrt die Dinge ein wenig für mich.

Ein einfacher Trick besteht darin, immer Probleme als Erinnerung zu erstellen. Es genügt, wenn sie den Titel, eine Eigenzuordnung und eventuell die Fehlermeldung enthalten. Sie können sogar ein Problem erstellen, um daran zu erinnern, ein weiteres Problem für CMake zu erstellen.

In der Tat. Ich habe auch das 0.9.4-Tag manuell auf Master gesetzt und verschoben. Ich gehe davon aus, dass dies eine Vorsichtsmaßnahme war.

Wenn beim nächsten Mal alles glatt laufen soll, können wir dies auch automatisieren.

Alle 21 Kommentare

Hier können wir auch andere Aufgaben sammeln, die uns vielleicht noch nicht bewusst sind, damit wir beim nächsten Mal eine vollständige Vorlage erhalten.

@mpranj können wir die Veröffentlichung in den nächsten Tagen machen? Welche Hilfe wird benötigt?

Ja, am liebsten würde ich die Veröffentlichung diese Woche machen, also spätestens Sonntag. @robaerd sollen wir die Veröffentlichung gemeinsam in einer Telefonkonferenz durchführen oder würdest du es vorziehen, dass ich die Veröffentlichungspipeline einfach selbst ausprobiere?

Ich denke, keine Hilfe, außer vielleicht wird Unterstützung von @robaerd benötigt. Wie besprochen planen wir für 0.9.4 keine großen Änderungen mehr. Die anderen können helfen, indem sie an der nächsten Version arbeiten. Wir müssen sowieso einige Ausgaben auf 0.9.5 verschieben.

Ja, ich denke, die gemeinsame Veröffentlichung ist eine gute Idee.

Ja, wir schaffen das zusammen, ich habe in den nächsten Tagen tagsüber Zeit.

@mpranj

Ich habe noch nicht überprüft, wie die Website all diese internen Verweise wiedergibt. Hast du es dir schon angeschaut?

Mmh, und clang-format-9 ist nicht mehr ohne weiteres verfügbar. Können wir auf Clang-Format-12 upgraden? Immer gut, dies bei einer Veröffentlichung zu tun.

Ich habe den Top-Beitrag aktualisiert.

Ich habe noch nicht überprüft, wie die Website all diese internen Verweise wiedergibt.

Nein, habe ich nicht, die Datei _preparation* wird nicht gerendert, bis wir den endgültigen Dateinamen ändern.

Können wir auf Clang-Format-12 upgraden?

Unsere Formatierungsprüfung läuft auf Debian Sid, afaik clang-format-11 ist verfügbar, aber nicht 12. Es wäre großartig, dies zu verwenden, da 11 auch die Version von Homebrew ist.

Ja, 11 ist perfekt. 11+12 ist verfügbar unter https://apt.llvm.org/

Ja, 11 ist perfekt.

Ich mache die PR.

Vielleicht ist es besser, wenn wir die <a id="..."></a> Tags über die Überschriften verschieben, sonst ist nicht klar, wohin Sie gesprungen sind.

Ich habe den oberen Beitrag aufgeräumt. Bei (etwas wie) #3641 sollte alles gut genug für die Veröffentlichung sein.

@mpranj @robaerd vielen Dank für deine fantastische Arbeit an dieser Veröffentlichung! :funkelndes_herz:

@markus2330 vielen Dank auch für Ihre Arbeit. Ich plane, die Veröffentlichung morgen durchzuführen, nachdem ich das Clang-Format PR korrigiert und wahrscheinlich den fehlgeschlagenen dbus-Test deaktiviert habe.

@robaerd beim Packen aus der Release-Pipeline erhalte ich einige Fehler wie:

CMake Warning (dev) at /usr/share/cmake-3.13/Modules/Internal/CPack/CPackDeb.cmake:541 (message):
  Shared library './usr/lib/elektra5/libelektra-c.so' is missing soname or
  soversion.  Library will not be added to DEBIAN/shlibs control file.
Call Stack (most recent call first):
  /usr/share/cmake-3.13/Modules/Internal/CPack/CPackDeb.cmake:676 (cpack_deb_prepare_package_vars)
This warning is for project developers.  Use -Wno-dev to suppress it.

elektra_0.9.4-1.build.error.txt

Ist das zu erwarten oder tritt es nur bei mir auf?

Dies wird erwartet (siehe https://github.com/ElektraInitiative/libelektra/pull/3583#issuecomment-743788271).
Leider habe ich keine Möglichkeit gefunden, diese Warnungen auszublenden.

Kein Problem, ich wusste es einfach nicht. Wegen der Doku war ich etwas zögerlich:

Check if the package build log has warnings 

Tut mir leid, dass ich das vergessen habe zu erwähnen, ich werde dies in der nächsten PR der Doku hinzufügen.
Ich habe auch ganz vergessen, einen Fehlerbericht darüber zu erstellen, wie @markus2330 in https://github.com/ElektraInitiative/libelektra/pull/3601#issuecomment -748850500 vorgeschlagen hat. Werde das in den nächsten Tagen machen. Alles auf mehrere PRs verteilt zu haben, verwirrt die Dinge ein wenig für mich.

@mpranj wird auch die Warnung "CPACK_RPM_PACKAGE_RELOCATABLE wird deaktiviert, weil CPACK_SET_DESTDIR gesetzt ist" während der CPack RPM Generierung erwartet (siehe https://github.com/ElektraInitiative/libelektra/pull/3601#issuecomment-748648426).

Der FTP-Veröffentlichungsschritt ist aufgrund eines fehlenden git add . fehlgeschlagen. Alles andere scheint erfolgreich gewesen zu sein.

Der FTP-Publishing-Schritt ist aufgrund eines fehlenden git add fehlgeschlagen.. Es scheint, dass alles andere erfolgreich war.

In der Tat. Ich habe auch das 0.9.4-Tag manuell auf Master gesetzt und verschoben. Ich gehe davon aus, dass dies eine Vorsichtsmaßnahme war.

Ich danke Ihnen beiden für Ihre Arbeit an dieser Veröffentlichung. Die neue Pipeline hat wunderbar funktioniert.

Alles ist fertig, aber ich werde bekannt geben, sobald sich die Build-Server eingerichtet haben (Cirrus und Travis sind heute etwas langsam..).

Scheint, als wäre die Veröffentlichung jetzt fertig :fireworks:

Ich habe auch ganz vergessen, einen Fehlerbericht darüber zu erstellen, wie @markus2330 in #3601 (Kommentar) vorgeschlagen hat. Werde das in den nächsten Tagen machen. Alles auf mehrere PRs verteilt zu haben, verwirrt die Dinge ein wenig für mich.

Ein einfacher Trick besteht darin, immer Probleme als Erinnerung zu erstellen. Es genügt, wenn sie den Titel, eine Eigenzuordnung und eventuell die Fehlermeldung enthalten. Sie können sogar ein Problem erstellen, um daran zu erinnern, ein weiteres Problem für CMake zu erstellen.

In der Tat. Ich habe auch das 0.9.4-Tag manuell auf Master gesetzt und verschoben. Ich gehe davon aus, dass dies eine Vorsichtsmaßnahme war.

Wenn beim nächsten Mal alles glatt laufen soll, können wir dies auch automatisieren.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

markus2330 picture markus2330  ·  3Kommentare

mpranj picture mpranj  ·  3Kommentare

markus2330 picture markus2330  ·  4Kommentare

markus2330 picture markus2330  ·  3Kommentare

e1528532 picture e1528532  ·  4Kommentare