Inoffizielles deutsches Xbase-Forum

Hallo,

wenn ich eine Software verkaufe, die ich nach Continuous Delivery-Prinzip entwickle, ist ja die Version relativ lange die Gleiche. Da habe ich überhaupt kein Problem mit, da lebe ich seit fast 30 Jahren mit. Aber Andere meinen damit zu vermitteln, das sich ja in letzter Zeit nichts getan hat an Weiterentwicklung.

Und vor genau dem Dilemma stehe ich jetzt. Ich habe die Chance, mein Programm auf einer Fach-Software-CD zusammen mit anderen Vertretern auf dem Gebiet unter die Leute zu bringen. Der Vermarkter meint aber, das die niemals die gleiche Version mehrfach nehmen würden. Das würde den Käufern Stillstand suggerieren, und sowas wollen die nicht anbieten. Insbesondere, da die letzte CD dann schon drei Jahre alt wäre. Auf der war ich das erste mal mit dabei. Und ich immer noch auf der gleichen Version stehe. Die Version davor gab es übrigens 6 Jahre.

Nachdem ich denen lang und breit erklärte habe daß sowas heute durchaus üblich sei, und selbst MS das mit Windows 10 und Office 365 schon seit Jahren so zelebriert, hatten die dann doch ein Einsehen. Wollen aber trotzdem irgendwie den Fortschritt der Software darstellen.

Die denken da an Sachen wie "MeinProgramm 4.0 (Softwarestand 11/2018)" oder "Meinprogramm 4.0 Build nnn".

Das kommt mir aber alles irgendwie unschön vor. Bei der Builds-Version kommt noch dazu, das meine Builds sich noch nicht wie bei Windows 10 in werbewirksamen mittleren 10.000er Regionen bewegen. Ich bin da je nach Datei in oberen 2- bis unteren 3stelligen Bereichen. Was sicher auch daran liegt, das ich immer nur bei einer Veröffentlichung hochzähle, nicht bei jedem internen Neuaufbau.

Habt Ihr da eine nette Idee zu?

Jan

Also ich hab bei meiner Anwendung eine Versionsnummer, die ist so etwas wie 2.01.047.
Die Version 2.00.xxx lief ein paar Jahre, dann nach einer großen Umstellung die 2.01.xxx.
Bei neuen Veröffentlichungen wird nur die letzte Nummer hochgezählt.
Meine Version mir XBase 2.0 bekommt dann die 3.01.001 etc.
Diese Nummern sind auch über die Eigenschaften in den exe- und dll-Dateien sichtbar.
Ohne Versionsnummern wüsste ich ja bei z.B. Fehlermeldungen nicht, welche Version es betrifft.

Wolfgang,

klar. Die Buildnummern trage ich auch immer ein. Ursprünglich hatte ich das wegen der Updateroutine gemacht, damit ich immer weiß welche der Dateien ich austauschen kann/muß. Aber klar, auch in den Fehlermeldungen ist das wichtig.

Ich finde allerdings das es merkwürdig aussieht wenn auf der Verpackung steht "MeinProgramm 4.0.0.95". Daher meine Frage, ob es da nicht irgendwas netteres gibt um klar zu machen, das es nicht mir die Version 4 von vor drei Jahren ist.

Jan

Hallo, Jan -


"4.0.0.95, aktualisiert am 18.07.2018"

Man kann es natürlich auch wie MS machen, Jahr und Monat in die Versionsnummer.

Jan, wenn du immer die gleiche Versionsnummer führst, warum verwendest du diese dann?

MainProgramm April18

oder halt

MeinProgramm V4 April18

Ich würde es wie M$ machen
Nur als Beispiel:
Office 2013 - würde bei Dir MeineFamilie 2013
Office 2016 - MeineFamilie 2016
Deine interne Versionsnummer kannst Du ja lassen.

Ich nutze auch die Version wie bei Xbase+++

a.bbb.cccc

a wird geändert, wenn deutliche Leistungsunterschiede enthalten sind. Beispiel von Clipper auf GUI oder neue Module dazu kamen (bisher nur Aufgabe X, nun zusätzlich Y)
bbb wird geändert, wenn in den bestehenden Modulen Erweiterungen / Änderungen vorgenommen wurden
cccc sind kleine / interne Änderungen bzw. Fehlerkorrekturen

Die a Nummern meiner Programme liegen bei 2 oder 3

Wenn es Änderungen gab, solltest du die auch nennen können, gerade bei einer GUI Anwendung, die ausgereift ist, wird sich da nicht mehr viel tun.
bbb und cccc dokumentieren, dass die Software noch gepflegt wird, die bbb sind durchaus erwähnenswert in der Programm Doku / Werbung ...

Diese ganzen Diskussionen um Versionsnummern.....
Versionsnummern solten doch nur dem Grund dienen, das man unterscheiden kann welche Programmversion gerade in Benutzung ist, bzw. was wann wie gemacht wurde am Programm. Es ist m.E. vollkommen unsinnig was anders daran festzumachen. Früher vielleicht bei den Prozessoren 8080 80286 80386.... Ok, aber heute? Firefox und Konsorten springen jetzt im 60er Bereich herum. Aber was bringt das? Es sagt überhaupt nichts über die Qualität der Programm aus. Eine Software muß den Anforderungen entsprechen und nicht den Versionsnummern hinterher hecheln. Das ist wie mit den quartalsmäßigen Updates. Die kann man verschicken, aber es tut sich vielleicht nicht viel darin. Das ist m.E. genauso wie der optische Schnickschnack der oft gefordert wird. Er bringt nicht viel, aber kostet unnötige Entwicklerzeit und bläst die Anwendung vielleicht nur unnötig auf und beinhaltet evtl. sogar noch Fehler und Probleme, die ohne dem nicht wären. Fragt doch mal wirklich nach, ob der Anwender überhaupt weiß, welche Unterschiede zwischen den Versionsnummern vorherrschen. Und vor allen Dingen ob diese Unterschiede wirklich wichtig für die Arbeit sind. Dann kommt in der Regel:" Tja, öhm, ja aber die Versionsnummer ist höher".
Ich für meinen Teil habe jedes sichtbare Programm(teil)fenster mit einem Zeitstempel versehen, dem ich immer das zuletzt aktuelle Datum eintrage, an dem es geändert wurde. Der Hauptbildschirm erhält grundsätzlich das allerletzte Datum, an dem überhaupt etwas geändert wurde. Sollte an einem Tag mehr gemacht worden sein aus irgendeinem Grund und dadurch der Anwender die Versionen gewechselt haben an dem Tag, dann kommt da eben ein Buchstabe hinter a,b,c.... und gut ist.
Bisher hat es meine Kunden nie interessiert, was da oben in der Versionsangabe steht. Aber ich konnte sehr schnell nachvollziehen wann, was gemacht wurde und evtl. irgendwas verursacht hat. Das ist für mich wichtig. Der Rest ist wie ein hinterherhecheln nach der neuesten Mode, die irgendwer bestimmt/vorschlägt.
Aber das ist nur meine Meinung.
PS: Und wenn sich eine Versionsnummer über längere Zeit nicht mehr ändert, könnte der Grund auch darin liegen: "Das Programm erfüllt seinen Zweck und ist nahezu perfekt und muß nicht geändert werden." Also evtl. auch ein Qualitätsbeweis

Hallo Jan !

Habt Ihr da eine nette Idee zu?

Machs doch wie Mozilla
FireFox und Thunderbird haben zweistellige Hauptnummern (62.0b9 und 60.0b10)
Das gibt doch was her und der Anwender sieht, die tun was

Moin alle zusammen,

Danke für die vielen Tipps und Hinweise. Ich will mal ein paar Anmerkungen dazu machen - und um Mißverständnissen vorzubeugen: Ich meine die alle nett und höflich

1) Die Versionierung mache ich ja schon. Hauptversionsnummer bleibt gleich - daran ziehen die CD-Kompilierer sich ja auf. Nebenversionsnummer führe ich nicht, möchte ich eigentlich auch vermeiden. Gleiches gilt für die Revisionsnummer. Was ich mitführe ist die Buildnummer. Daher ja die oben bereits zitierte 4.0.0.95

2) Da ich die mitführe, werden die im Explorer auch angezeigt. Der Benutzer kann das also sehen. Abgesehen davon gibt es im Programm auch ein Infofenster, in dem ebenfalls die vollständigen Versionsnummern aller benötigten Dateien aufgelistet werden.

3) Es geht ja nicht darum, das der Kunde das im Explorer oder sonstwo sehen kann. Sondern darum das die CD-Kompilierer in ihrem Datenblatt nicht einfach nur die "4" sehen wollen, die es schon vor drei Jahren da gab. Die wollen, wenn ich das nicht ändern will (was die inzwischen zum Glück akzeptieren), irgend eine Ergänzung sehen - die aber natürlich in meinen Augen auch werbetechnisch ansprechend aussehen sollte. Und da finde ich als Aufmacher auf der Verpackung halt ein "MeinProgramm Version 4.0.0.095" irgendwie doof. Was die CD-Kompilierer vorschlagen finde ich aber ebenfalls etwas sperrig - ich hatte ja im Eingangspost zwei Varianten zitiert: "MeinProgramm 4.0 (Softwarestand 11/2018)" oder "Meinprogramm 4.0 Build nnn". Vielleicht muß ich mich auch einfach nur an den Gedanken gewöhnen, doch eines der beiden zu nehmen. Aber bis dahin bin ich halt für gute Alternativen sehr dankbar.

4) Ergänzung: Die Versionierung "MeinProgramm 4 1807" wäre natürlich eine Idee. das kennen die Leute durch Windows 10 ja inzwischen, die Linuxleute schon länger, aber da läuft mein Programm nicht . Dumm nur das ich manchmal, wenn es gut läuft, auch mal zwei Versionen in einem Monat rausbringe. Aber es wäre zumindest für diese CD überlegenswert. Und ob ich das nicht generell mitführen würde. Muß ich mal etwas in mich gehen.

Vielleicht habe ich mein Anliegen damit etwas klarer darstellen können.

Jan

Manfred, Manfred, welche weissen Mäuse laufen dir über die Leber?

Manfred hat geschrieben: ↑Do, 19. Jul 2018 8:25 Er bringt nicht viel, aber kostet unnötige Entwicklerzeit und bläst die Anwendung vielleicht nur unnötig auf und beinhaltet evtl. sogar noch Fehler und Probleme, die ohne dem nicht wären. Fragt doch mal wirklich nach, ob der Anwender überhaupt weiß, welche Unterschiede zwischen den Versionsnummern vorherrschen. Und vor allen Dingen ob diese Unterschiede wirklich wichtig für die Arbeit sind. Dann kommt in der Regel:" Tja, öhm, ja aber die Versionsnummer ist höher".

Also da bin gar nicht deiner Meinung. In jedem meiner Programme ist ein Was-ist-neu-Button unter der Hilfe. Weiter wird mittels Newsletter informiert, was denn nun Wichtiges neu ist. Also: Information zum Kunden hin, die sehr wohl wahrgenommen wird. Dass man zur Orientierung für siche eine Versionsbezeichnung braucht, ist klar.

Manfred hat geschrieben: ↑Do, 19. Jul 2018 8:25 PS: Und wenn sich eine Versionsnummer über längere Zeit nicht mehr ändert, könnte der Grund auch darin liegen: "Das Programm erfüllt seinen Zweck und ist nahezu perfekt und muß nicht geändert werden." Also evtl. auch ein Qualitätsbeweis

Das gibt es in der Welt der Programme niemals. EIn Programm ohne Kundenfeedbacks vielleicht, aber das würde ja heissen, es ist nirgends installiert. Eigene neue Ideen, neue Compilermöglichkeiten usw. verhindern einen Status-Quo. Und - oft ist man mit seiner Programmlösung nicht alleine im Markt, man muss also vorne bleiben. Das geht nur mit Kundennähe und entsprechenden Anpassungen und Erweiterungen.

Und warum soll auf jedem Programmfenster ein Zeitstempel stehen? Das verstehe ich gar nicht.

Herbert,

da muß ich Dir mal zustimmen;-)

Ich benutze für Software, die unter die Leute kommt, grundsätzlich Versionsnummern. Einerseits ist das gut in der Kommunikation ("Welche Version haben Sie denn installiert?"). Ich bekomme auch die Fehlerprotokolle mit den Versionsnummern aller von mir gelieferten exe und dll mit - egal ob meine Dateien oder die von Alaska oder sonstwem. Dann kann ich alleine daran schon mal eine Menge festmachen.

Ich nutze das aber auch für die automatischen Updateroutinen. Dadurch, das die Versionsnummer per arc immer eingepflegt ist in die Datei, und ich die da auch auslesen kann, hab ich mit Updates eigentlich nichts mehr zu tun. Außer die zur Verfügung zu stellen. Alles andere läuft vollautomatisch ab.

Und selbstverständlich gibt es auch eine Versionshistorie. Die der Kunde auch in seinem Programm ansehen kann.

Klar hat eine Datumsangabe der aktuellen Version auch was für sich. Einerseits sieht der Kunde, von wann die Software ist, ob es da was neueres gibt. Das wäre dann ähnlich die Versionsnummern. Andererseits ist das auch Werbeeffekt: Wenn die Version, mit der er arbeitet, x Jahre alt ist, dann wird er eventuell selber mal nachfragen, ob es nicht was neueres gibt. Eine einfache Versionsnummer wird ihn da vermutlich nicht so einfach drauf stoßen. Die gibt ja nur im Kontext mit anderen Versionsnummern eine Art Alter an.

Ob in jedem Dialog ein Datum oder eine Version stehen muß sei mal dahin gestellt. Ich selber finde das nutzlos. Es mag aber Anwendungen geben, wo das durchaus Sinn macht. Mir fällt nur gerade keiner ein ... (das meine ich nicht lästerlich. ich arbeite vielleicht einfach nicht in der Branche, wo das sinnvoll ist).

Jan