[Semi-OT] Schreibanfall

Hallo allerseits!

Ich hatte wieder einen Schreibanfall. Da ich gerade keinen Fehler mehr entdecken kann, aber weiß, wie gut das Hirn, das etwas ausgebrütet hat, Fehler wegbügelt, bitte ich Euch, den Abschnitt „Versionierung“ ganz unten auf dieser Seite durchzulesen und mir mitzuteilen, ob da noch etwas fehlt oder falsch ist.

Sonstige Kommentare sind natürlich auch willkommen.

Vielen Dank vorweg!

Gregor

Hi

Beim Drüberlesen wäre mir Nichts aufgefallen.
Aber eine Frage hätte ich - selber habe ich das Speichern beim Kompilieren ABgeschaltet, da ich mir so früher öfter 'was zersemmelt' hatte.
Klar, keine Lösung ohne Fehler-99 (Osi-Schicht 8) Möglichkeit: Ein erneut kompilierter Sketch landet SO dann natürlich nicht auf der Platte.
Wenn ich nun die Programmier-VM (Programmiere in Win 7 auf Linux Mint - in Win ist die IDE schöner) runterfahre, ist der neuste Sketch futsch - wieder was gelernt.

Wie machst Du Das nun mit Deinen Versions-Nummern?
Mir fiel jetzt nur der Weg ein, bei jeder halbwegs brauchbaren Änderung 'Speichern unter' anzuwählen und einen neuen Ordner/Namen für den Sketch einzugeben.

MfG

PS: Alter Sesselpuper :wink:

PPS: Meine 'Versionen' sind meist der Sketch-Name mit den eingebauten Änderungen, so z.B.: HeizungsSchieber_Sketch_Klassen_Serielle_Befehle
(dem Sketch kann ich 'befehlen', was Er machen soll, nutzt Klassen und soll Mal meine(n) Heizungsschieber befeuern.

Ich habe mir unter Win7 ein System geschaffen, dass mir automatisch bei jedem Speichern eine Version der Files mit Datum/Uhrzeit hinten dran abspeichert.

Das besteht aus einer .bat/.cmd-Datei, um die Rechteverwaltung von Win auszutricksen (ja, so einfach geht es) und einer powershell (.ps1) Datei im Sketchfolder.

Wenn Interesse besteht, poste ich sie.

Damit wird jede .ino, .h., .cpp im Sketchfolder bei jeder Änderung gesichert (also der neue Stand - evtl. vorher mal ein Space eingeben und speichern)

Das kann kein Versionsverwaltungssystem ersetzen, hilft aber, wenn man sich verrant hat. Nur ans Starten muss man selbst denken.

Gruß Tommy

postmaster-ino:
... Wie machst Du Das nun mit Deinen Versions-Nummern?

Mir fiel jetzt nur der Weg ein, bei jeder halbwegs brauchbaren Änderung 'Speichern unter' anzuwählen und einen neuen Ordner/Namen für den Sketch einzugeben.

Ja, genau so mache ich das auch. Ein neuer Sketch bekommt Versionsnummer 0.1 (erst nach 9 weiteren Änderungen wird es zur Version 0.10). Bis ungefähr Version 0.3 muss ein Sketch noch nicht funktionieren. Da benutze ich die Versioniererei lediglich, um verschiedene „Entwürfe“ festzuhalten.

postmaster-ino:
PS: Alter Sesselpuper :wink:

PPS: Meine 'Versionen' sind meist der Sketch-Name mit den eingebauten Änderungen, so z.B.: HeizungsSchieber_Sketch_Klassen_Serielle_Befehle
(dem Sketch kann ich 'befehlen', was Er machen soll, nutzt Klassen und soll Mal meine(n) Heizungsschieber befeuern.

Ich stehe zu meinem Alter :stuck_out_tongue:

Das Problem mit Deiner Art der Versionierung ist, dass Du evtl. nicht mit Sicherheit sagen kannst, in welcher Reihenfolge die Änderungen erfolgt sind. Ich habe mal in einer Firma gearbeitet, die zwar fleißig gesichert aber keine Versionsnummern verwendet hat. Falls in „letzte_version“ noch eine Korrektur anfiel, wurde die zu „allerletzte_version“. Was in mehrfacher Hinsicht scheiße ist.
Was Du im Datei-/Ordnername notierst, würde ich eher in README oder CHANGELOG festhalten. Das ist zwar auch wieder Zeug, das nach Sesselpuperei aussieht, aber solange man zu seinem Alter steht, ist das okay :slight_smile:

Gruß

Gregor

Ich versioniere manuell.
“Gut” funktionierende Versionen sichere ich einmal mit der Versionsnummer in ein neues Verzeichnis. Ich hänge dazu einfach die Versionsnummer dran.
Versionswechsel mache ich wenn ich sie auf die produktiven Boards deployed habe um einen fixen Stand zu haben, auf den man retour kann.

Zur Dokumentation habe ich im Sketch ziemlich weit oben ein Precompiler-Define, das ich aber auch öfters im Code verwende und ausgebe, wo es mir hilft.

Weil ich es gerade offen habe, ein Beispiel:

#define VERSION "2.22"          // This is just the Version of the Arduino Sketch

am Anfang vom Setup, damit ich über die Serielle beim starten sehe, was da drauf ist

  Serial.println(F("   LCD LED DHT SERVER CLIENT AJAX MEGA - Version: " VERSION));

im webclient lass ich mir in einem Parameter die Version mitschicken und sehe so an zentraler Stelle (wohin die meisten Boards hinreporten) welche Version auf welchem Board im Einsatz ist

   strcat(message, "&ver=" VERSION);                   // Version of this software

und wenns ein Webfrontend (Webserver) gibt, häng ich die Versionsnummer meist noch in die Fußzeile

   client.print  (F("</span> " TXT_SECONDS "
 " TXT_VERSION " " VERSION " - " __DATE__ ", " __TIME__ "</p>\n</footer>\n</body>\n</html>"));  // Variante ohne zusätzlichem Informationsfeld

Ab und zu lösche ich “alte” Versionen (Verzeichnisse).

@gregorss: Unter Linux wäre das mir “inotify” machbar.

Gruß Tommy

Ich habe mir inzwischen angewöhnt, alles an dem ich längere Zeit arbeite, mit Git zu versionieren. Es erfordert zwar ein wenig Einarbeitung, bietet aber eine Menge Möglichkeiten bei der Entwickung und Versionierung.
Das funktioniert übrigends durchaus rein lokal. Es ist nicht notwendig, ein Repository auf GitHub zu erstellen und die Software hochzuladen.

Wobei eine Versionierung die regelmäßige Datensicherung natürlich nicht ersetzen kann :wink:

Mir ist noch eine andere Variante bekannt: Testversionen werden mit einer 99 beginnent runtergezählt. Funktionierende Versionen erhalten eine 1 aufwärts. Also:

1.99, 1.98, 1.1, 1.2.99, 1.2.98, 1.2.1, 2.99, 2.98, 2.97, 2.1

Ich nutze das nicht, sondern nummeriere einfach aufwärtszählend, die höchste Nummer ist mit der aktuell eingesetzten Version gleich.

agmue:
Mir ist noch eine andere Variante bekannt: ...

Mir leuchtet nicht ein, wie Du das meinst. Wenn ich einfach nur die Versionsnummer 1.99 sehe, kann ich nicht sagen, ob das nun eine Testversion ist oder eine „fertige“. Ich sehe ja nicht, ob da gerade herunter- oder hochgezählt wird. Oder doch?

Gruß

Gregor

gregorss:
Ich sehe ja nicht, ob da gerade herunter- oder hochgezählt wird. Oder doch?

Siehst Du nicht. Aber in der mir bekannten Praxis waren die Zahlen aber immer nahe 1 oder 99, wobei nahe an 1 eben "funktionierend" und nahe an 99 "noch im Test" bedeutet. Wenn Du in der Regel mehr Versuche benötigst, kannst Du das Spiel auch mit 1 und 999 machen.

Alles > X.50 wird wohl eine Testversion sein, alles < X.50 eine Produktive.
Es gibt ja selten so viele Sub-Versionen, dass man mit 50 auskommen sollte. Das denke ich ist die Theorie dahinter.

Finde es aber eher seltsam und nicht intuitiv. Gefühlt ist die höhere Version immer die neuere. Unabhängig ob Prod oder Test. Daher würde ich persönlich nach diesem System erstmal die falsche verwenden.

Eine imho bessere Variante ist: Gerade Release, Ungerade Nightly build/Test.

Weiterhin bin ich auch der Vertreter von 3 Stellen:
2.0.0 Major (Breaking change zu 1.0.0)
2.1.0 Minor (Z.B. neues Feature, aber weiterhin kompatibel)
2.1.1 Patch (Fehlerbehebung)

Aber wir schweifen vom eigentlichen Thema ab :wink:

TriB:
Daher würde ich persönlich nach diesem System erstmal die falsche verwenden.

Du darfst raten, warum ich mir das so gut gemerkt habe :slight_smile:

Das System wurde von einer großen Firma international verwendet, die müssen sich ja was dabei gedacht haben, hoffe ich.