Versionierung einführen

[OnDemand]

Hallo zusammen,

wir bauen demnächst unsere Software um und beginnen von Null.

Ich möchte direkt Versionierung nutzen im einen besseren Plan zu haben(hab ich bisher nicht gemacht).

Derzeit bin ich der einzige Entwickler, daher hab ich bisher drauf verzichtet, sehe aber die Vorteile.
Jetzt hab ich einige Fragen:

2)
Wie könnte ich am besten versionieren? Wie ein größeres Team arbeiten und mir Ziele für X Wochen setzen und dann eine neu einsetzen Version releasen (Sprints) oder nach jedem neuen Feature eine neue Version freigeben? Die Nutzer würde es vermutlich freuen, wöchentlich Updates zu bekommen.

3) Wie genau kann man möglichst einfach die Versionen verwalten also quasi hochzählen - im Einsatz hab ich Bitbucket und Jenkins.

4) wie arbeitet ihr bugs, Features und co ab? Habt ihr ein entwicklungsrepository welches ihr für jeden bug, Feature usw forked und dann dort wieder rein merged?

Könnte mir dann vorstellen 2-3 Tage vor Release alles zu testen (testen lassen) was eingebaut wurde Id dann dann das getestete Enticklerrepo in den Master mergen?!

würde mich freuen wenn jemand den ein oder anderen Tipp hat. Ziel ist es schneller ans Ziel zu kommen und Änderungen besser verfolgen zu können und ggf. Zurückzurollen

 

[LimDul]

Gibt mehrere Möglichkeiten für das Versionsschema, ein relativ populäres ist: https://semver.org/lang/de/

Bzgl. des Workflows ist ein populärer git-Flow: https://www.atlassian.com/de/git/tutorials/comparing-workflows/gitflow-workflow

 

[OnDemand]

Danke, da hab ich ja eine Bettlektüre für heut

 

[LimDul]

Mir ist noch was aufgefallen.

Die Nutzer würde es vermutlich freuen, wöchentlich Updates zu bekommen.

Ich kenne jetzt die Software und die Benutzer nicht - aber im kommerziellen / Enterprise Bereich würde ich diese Aussage hinterfragen. Je nach dem wo und wie die genutzt wird, hat der Kunde keinen Bock jede Woche ran zu müssen. Daher würde ich sowas tatsächlich mit den konkreten Kunden klären - was sind deren Erwartungen. es gibt ja das berühmte Bild mit der Schaukel (Google: Schaukel Projekt). Da ist viel wahres dran. Als Entwickler ist man oft extrem weit weg von den Nutzern bzw. kennt nur einen Teil der Stakeholder. Den Nutzer sind das eine, Betrieb etc. der andere. Reden hilft bei sowas ungemein.

Deswegen - Erwartungen abfragen
* Wie oft will eine Kunde überhaupt eine neue Version haben? (Bugfixes/kosmetische Änderungen/neue Features)
* Wie oft will er neue Features haben?
* Was ist im eigentlich wichtig?

 

[httpdigest]

wir bauen demnächst unsere Software um und beginnen von Null.

Ich möchte direkt Versionierung nutzen im einen besseren Plan zu haben(hab ich bisher nicht gemacht).

Vergewissere dich erstmal, was eine Versionsnummer denn eigentlich aussagen soll.
Semantic Versioning (also eine Versionierung mit einer Semantik/Bedeutung), wie ja von @LimDul referenziert, macht bei Libraries mit einer API Schnittelle Sinn, um dem Client/Nutzer der API einen Kontrakt bezüglich kompatibler und inkompatibler Änderungen und Erweiterungen der API zu kommunizieren.
Also, welche Versionen einer API bzw. Library können einfach automatisch hochgezogen werden, ohne syntaktische (z.B. Methodensignatur) oder semantische (Methode tut jetzt einfach was ganz anderes) inkompatible Änderungen zu befürchten.

Wenn deine Software allerdings keine Library mit API ist, sondern z.B. ein GUI Tool, dann musst du dir Gedanken darüber machen, welchen Kontrakt bzw. welche Zusicherungen du dem Nutzer gegenüber mit einem Versionierungsschema eigentlich geben willst. Das kann z.B. sein, dass du sagst: "Version 1.0 kann problemlos zu Version 1.1 upgegraded werden, weil Version 1.1 immer noch das Dateiformat von Version 1.0 lesen und schrieben kann. Version 2.0 hat allerdings keine Abwärtskompatibilität mehr zu Dateiversionen von 1.x. Deswegen heisst diese Version 2.0."

Im besten Fall hat also eine Versionsnummer immer eine zum Nutzer hin ausgerichtete Bedeutung über bestimmte Kompatibilitätszusagen. Wenn du solche Zusagen aber nicht machen möchtest, und deine Versionsnummer eigentlich nur eine fortlaufende Nummer ist, dann mach es so wie Chrome/Firefox oder du einfach nur z.B. ausdrücken willst, dass ein Release innerhalb eines bestimmten festen Zeitraumes erschienen ist, dann mach es so wie Java (ab Version 9).

Im Endeffekt solltest du dich also erstmal fragen: Welche für Benutzer relevanten Informationen sollte ich in einem Versionierungsschema kommunizieren?

 

[OnDemand]

Danke vielmals!
Im Prinzip muss der User wissen zb in Version 1.2 wurde der Import für die TXT Datei angepasst, es muss nun eine andere Quelldatei importiert werden.

Weiß nicht ob das Sinn ergibt, denn schließlich könnten wir dem User anzeigen „ey falsche Datei“
Für intern macht das vielleicht eher Sinn, dass man ab Version 1.2 eine andere Dateistruktur braucht. So kann man vielleicht Fehler besser eingrenzen, die mit dem Import zu tun haben, da er schließlich erst mit 1.2 eingeführt wurde.