C-toxcore: Toxcore-Versionierungsschema

Erstellt am 23. Sept. 2016  ·  3Kommentare  ·  Quelle: TokTok/c-toxcore

Anregung

Betrieb unter der Annahme, dass toxcore der semantischen Versionierung folgen wird. Ich schlage vor, wir übernehmen den uTox-Stil von sem-ver.

Es wird zwei Versionen von "Tracks" geben. Die erste existiert ~nur im Code und wird Git nicht ausgesetzt. Die zweite wird öffentlich veröffentlicht, in git getaggt und als „unterstützte“ Version dienen.

Dieses Schema ermöglicht eine schnelle Entwicklung außerhalb einer bestimmten Version und bei der Fehlerbehebung von Fehlern oder Problemen eine schnelle Identifizierung dessen, wo und was den Fehler verursacht haben könnte.

Der eigentliche Ablauf und die Tags, die ich vorschlage, folgen. (Und wird von akzeptierten Kommentaren in diesem Thread aktualisiert)

Beispiel:

git tag v0.0.0 e6af3a7825e8307a501bc7c3e7b1ff323f081870

Änderungen werden an der Toxcore-API vorgenommen (bereits durchgeführt), die im Code identifizierte Version sollte v0.1.0 lauten, aber diese Version wird Git nicht ausgesetzt (getaggt).

Nach Abschluss des zustandslosen ToxAV-Updates. Die Version im Code ist v0.2.0 , mit dem Zusatz von git tag v0.2.0 (dieses Commit kann optional in einen neuen Zweig stable gepusht werden).

Das allernächste Commit zu master ändert die Version zu v0.2.1 und alle/alle Commits werden in diesen Branch gemergt.**

Sobald eine neue Version bereit ist, auf Stable gepusht zu werden, wird die Version im Code mit git tag v0.2.2 auf v0.2.2 (optional v0.3.0 ) erhöht. Dieser Zweig wird auf stable verschoben.**

Das allernächste Commit zu master wird v0.2.3 sein und es wird kein Git-Tag für diese Version geben.

Diskussion

Entwickler können sofort wissen, ob ein Fehler in einer stabilen Version oder nur im Entwicklungszweig vorhanden ist oder ob er bereits in einem Entwicklungszweig behoben wurde.

Es erlaubt (zwingt) Paketbetreuer, nur stabile Versionen zu verwenden, wenn sie es wünschen, wenn sie eine Version paketieren und veröffentlichen (weil nur stabile Versionen gekennzeichnet werden.) Der einzige Vorbehalt dabei ist, dass Pakete möglicherweise unbeständig mit der von gemeldeten Version versioniert werden toxcore, wenn Paketierer blindlings die von git tag gemeldete Version verwenden.

Schließlich können Entwickler den Debug-Modus standardmäßig aktivieren, wenn sie feststellen, dass sie einen Entwicklungs-Build von Toxcore verwenden. ( toxcore_version_patch() % 2 )

Hilfreichster Kommentar

Ich schlage vor, wir übernehmen den uTox-Stil von sem-ver.

Nein, bitte führen Sie keinen Mist ein und verwenden Sie semver . Es gibt keine Stile .

v0.0.1 – keine stabile API, alles außer der API kann jederzeit kaputt gehen
v0.1.0 – Sie haben eine ~stabile API
v0.1.1 – API ist nicht kaputt, einige Korrekturen/Verbesserungen/interne Änderungen
v0.2.0 – Bruch in der API, andere Änderungen

So einfach ist das. Keine wahnsinnigen 2-Versions-Sprünge.

Es hat keinen Sinn, darüber zu diskutieren. Normen verwenden . Und nein, Ihre ganze Vorstellung von Verpackungen ist einfach falsch – Sie machen die Dinge nicht einfacher, sondern schwieriger, indem Sie ein viereckiges Rad neu erfinden.

Was Sie anscheinend tun möchten, ist, dem Beispiel von GTK/Gnome in Bezug auf die Versionierung zu folgen – etwas, das in der Verpackungswelt weithin als verzögert gilt. Darüber solltest du vielleicht mal nachdenken.

Vielleicht möchten Sie lernen, was semver ist, da das von Ihnen vorgeschlagene Versionierungsschema _nicht semver_ ist.

Wenn Sie etwas nicht als Tag in Git freigeben, wird es nicht gepackt. Zeitraum.
Wenn es markiert wird, ist es ein Release und wird gepackt.


Als Randnotiz; Sie brauchen keinen stable -Zweig – verwenden Sie git tag s.

Alle 3 Kommentare

@iphydf @nurupo @JFreegman @mannol @tux3 @zetok @chuongv

Ich schlage vor, wir übernehmen den uTox-Stil von sem-ver.

Nein, bitte führen Sie keinen Mist ein und verwenden Sie semver . Es gibt keine Stile .

v0.0.1 – keine stabile API, alles außer der API kann jederzeit kaputt gehen
v0.1.0 – Sie haben eine ~stabile API
v0.1.1 – API ist nicht kaputt, einige Korrekturen/Verbesserungen/interne Änderungen
v0.2.0 – Bruch in der API, andere Änderungen

So einfach ist das. Keine wahnsinnigen 2-Versions-Sprünge.

Es hat keinen Sinn, darüber zu diskutieren. Normen verwenden . Und nein, Ihre ganze Vorstellung von Verpackungen ist einfach falsch – Sie machen die Dinge nicht einfacher, sondern schwieriger, indem Sie ein viereckiges Rad neu erfinden.

Was Sie anscheinend tun möchten, ist, dem Beispiel von GTK/Gnome in Bezug auf die Versionierung zu folgen – etwas, das in der Verpackungswelt weithin als verzögert gilt. Darüber solltest du vielleicht mal nachdenken.

Vielleicht möchten Sie lernen, was semver ist, da das von Ihnen vorgeschlagene Versionierungsschema _nicht semver_ ist.

Wenn Sie etwas nicht als Tag in Git freigeben, wird es nicht gepackt. Zeitraum.
Wenn es markiert wird, ist es ein Release und wird gepackt.


Als Randnotiz; Sie brauchen keinen stable -Zweig – verwenden Sie git tag s.

Nur um zu korrigieren, was @zetok gesagt hat:

  • 0.0.0 – Erster Commit/nicht stabile API ;
  • 0.1.0 – API ist immer noch nicht stabil, aber es wurde eine neue Funktion hinzugefügt;
  • 0.1.1 – Immer noch nicht stabil, aber behebt einen Fehler/ein Problem/eine Sicherheitslücke;
  • 0.2.0 – Neue Funktion wird hinzugefügt und veröffentlicht;
  • 1.0.0 – Stabile API.

So soll semver funktionieren, RELEASE.FEATURE.PATCH .

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

zetok picture zetok  ·  3Kommentare

grinapo picture grinapo  ·  4Kommentare

iphydf picture iphydf  ·  9Kommentare

MrSorcus picture MrSorcus  ·  10Kommentare

tox-user picture tox-user  ·  9Kommentare