Ich habe aktuell keine Übersicht darüber, welche App-Version aktuell ist. Ich bin Beta-Tester uter Android und habe aktuell die 2.27.1 installiert. Dies scheint aber gleichzeitig auch die aktuellste nicht-Beta-Version zu sein, richtig? Um Feedback und Bugs hier in Zukunft richtig melden zu können, wünsche ich mir eine Kennzeichnung von Beta-Versionen in der App.
Dazu schlage ich vor, die Versionsnummer innerhalb der App (sowohl im gesperrten Zustand bei der Passwortabfrage, als auch innerhalb der Einstellungen) mit dem Kürzel „Beta“, oder einem „B“ zu versehen. Schreibt gern eure Meinung dazu, vielleicht auch mit besseren Lösungsmöglchkeiten.
2 „Gefällt mir“
Das ist eine sehr gute Idee. Ein einfaches B als Teil der Versionsnummer reicht schon völlig aus. Ohne die Anzeige einer Build-Nummer nur in der Beta, das wäre dann auch ziemlich eindeutig.
1 „Gefällt mir“
Klingt für mich so naheliegend, dass es fast ein bisschen peinlich ist, dass wir das nicht schon haben. Ich sprech mal mit den Entwicklern. Wenn es einen guten Grund gibt, warum das noch nicht so ist, melde ich mich.
Danke für die Idee!
Der Grund dafür ist, dass die App, die Du in der Beta testest, genau die App ist, die später auch live geht. Im Moment ist die Beta tatsächlich die gleiche Version wie die Live-App. Die nächste Beta kommt aber bald. 
Und die beta wird dann gekennzeichnet sein?
Das Problem ist ein bisschen, dass wir bei anderer Kennzeichnung wohl zwei verschiedene Apps aufsetzen müssten und die dann jeweils einzeln durch die Prüfung der Stores gehen würden. Damit müssten wir permanent 2 Apps pflegen (also 4, bei 2 verschiedenen Stores). So zumindest die Erklärung, warum wir das nicht machen von den Apps Teams.
Für den Moment empfehle ich einfach ,immer mal wieder in den aktuellsten Beta Thread zu schauen. Da schreibe ich auch rein, wenn eine App-Version live geht.
Kennzeichnung innerhalb der App meine ich. Nicht der Name der App in der App-Übersicht auf dem Smartphone.
Aber wie sollte das technisch funktionieren? Sobald die Beta-App nicht derselbe Code wie die Release-Version ist, braucht es zwei App-Fassungen bzw. eine Anpassung des Codes von Beta- zu Releasestatus. Ich glaube, der Versioning-Flow der Appstores ist dafür nicht ausgelegt. Ich nehme an, dass das das Versioning unverhältnismäßig verkomplizieren würde, würde man hier einen Workaround nutzen, der das irgendwie ermöglichen würde.
Ich glaube, ich habe das Problem auch nicht richtig verstanden: Warum sollte es für Bug-Reports ein Problem sein, wenn die Release-Version mit der aktuellen Beta-Version übereinstimmt? Bug ist Bug. Und es wird in den Entwicklungszyklen immer wieder Momente des „Leerlaufs“ geben.
1 „Gefällt mir“
Der Code muss identisch sein? Wie macht man dann Updates? Selbstverständlich ist es möglich, einen Text-String zu ändern oder hinzuzufügen oder zu entfernen, ohne direkt eine neue App publisher zu müssen.
Nein nein. Wir reden definitiv an einander vorbei.
1 „Gefällt mir“
Bzw: warum muss man zwingend die letzte beta auch public machen? Kann man nicht einfach die beta nehmen, den Text ändern, und dann live veröffentlichen?
Wir nehmen das Thema noch mal mit.
Logisch, das ginge. Das meinte ich damit, dass das „Versioning“ verkompliziert werden würde. Du müsstest zwei Versionen der gleichen App erzeugen, nur, um das anzeigen zu können. Das meinte ich mit „Workaround“. Die Appstores selbst sehen auf Ebene der Versionsnummern hier keine Differenzierung vor. Das ist aus Entwicklersicht natürlich auch sinnvoll, denn so kann man immer definitiv sehen, um welche Version es sich handelt. Version 12.1 im Betatest ist völlig identisch mit Version 12.1 als Release-Version. Wurden zwischen Betatest und Release-Version noch Fehler gefixt, geht 12.1 nie live, sondern vielleicht 12.1.5 oder so.
Yepp. Klingt ein bisschen wie eine Arbeitsbeschaffungsmaßnahme 
und erzeugt halt doppelt so viele App-Versionen wie nötig. Aber jetzt mal ganz ungeachtet meiner persönlichen Meinung dazu: Inwiefern ist das denn relevant? Ich kann das Ausgangsargument noch nicht nachvollziehen: Wie würde sich denn das Testverhalten und Bug-Reporting beim Betatest ändern, wenn man diese Info hätte? Ich kann hier nur aus der Sicht von iOS sprechen, wo Beta-Versionen tatsächlich durch iOS als solche gekennzeichnet sind, hier stellt sich die Frage also nicht. Aber wie würde das beim Bug-Reporting helfen? Die Live-Version „überholt“ unter normalen Bedingungen ja nie die Beta-Version.
Also ich denke es wäre die „einfachste“ Lösung wenn nicht zur Complie-Zeit, sondern erst zur Laufzeit feststeht, ob die App als Beta deklariert wird. Eine naive Idee wäre einfach die App die aktuelle stable-Versionsnummer per API-Call an Tomorrow zu erfragen und dann zu vergleichen mit der Eigenen.
Ob das ganze den Aufwand wert ist kann ich nicht wirklich einschätzen.
1 „Gefällt mir“
Diese Annahme setzt ja voraus, dass alle Builds dupliziert werden. Das stimmt aber in meiner Idee so nicht. Man müsste nur genau die allerletzte Beta nochmal ohne den Beta-Hinweis bauen (Änderung zur letzten Beta: „Beta-Hinweis unsichtbar“, sonst nix) und dann direkt als LIVE pushen. Fertig.
Klar ist das mehr Arbeit als einfach die letzte Beta „Live“ zu schalten, also weiter auszurollen. Es ist halt auf einen Blick klar, ob jemand die Beta nutzt oder nicht. Das ist bei einem Finanzprodukt schon nicht so dämlich
Ich als Entwickler würde versuchen zu vermeiden, dass die App-Versionsnummern so künstlich aufgeblasen werden. Diese Anpassung müsste dann ja ständig immer wieder aufs Neue stattfinden. Bevor man zu so einer kruden Lösung kommt, oder den Aufwand für @Johann s eleganteren Vorschlag betreibt, würde ich abklopfen, welches Problem hier denn eigentlich gelöst wird.
Fragen wären:
- Wie viele Beta-Tester vergessen, dass sie die Beta-Version installiert haben?
- Wie viele Leute wechseln häufig zwischen Release- und Beta-Version und verlieren deswegen den Überblick?
- Welches Problem von @Turbotomate wird hier eigentlich gelöst? Ist es für die Entwickler nicht einfach egal, ob sie einen Bug-Report in Thread 12.1 (Produktion) oder im Thread 12.1 (Beta) gemeldet wird? Denn wenn die Versionsnummer identisch ist, ist der Bug für „beide“ Releases gleichermaßen relevant. Ich sehe hier nicht, welche Notwendigkeit des Sortierens hier überhaupt bestünde, damit man einen Bug „richtig“ melden kann. Denn durch die Versionsnummer ist die Zuordnung bereits eindeutig. Entscheidend wäre das nur, wenn sich 12.1 (Produktion) von 12.1 (Beta) unterscheiden würde.
- Was bedeutet das für die Versionsnummernparität zwischen Android und iOS? (Hier sind Betas ja bereits durchs OS selbst gekennzeichnet.)
Für mich ist das die Kategorie „nice to have“. Ich würde aber Lösungsansätze wie laufend einen visuellen Hinweis manuell hin und her anzupassen nicht empfehlen.
2 „Gefällt mir“
Heieiei. Ich formuliere es mal als Bedarf:
Ich als Beta-Nutzer will wissen, ob die Version der App, die ich gerade nutze, eine Beta-Version ist oder nicht.
1 „Gefällt mir“
Das verstehe ich.
Sind dazu die Release-Notes nicht ggf. ausreichend?
Wem „Banking“ und „Beta“ in einem Satz zu riskant ist (fair enough), der muss ja nicht Betatester sein.
Ich kann tatsächlich wenig praktische Relevanz in der konkreten Information erkennen, dass gerade keine Funktionsumfangsparität zwischen Beta- und Normalfassung herrscht.
Ganz konkret: Unter welchen Umständen würde ein Nutzer welche Entscheidung von dieser Information ableiten?
Mir fällt es schwer, einen konkreten Kundennutzen zu sehen. Wenn die Beta-Version auf meinem Device nicht funktioniert, lösche ich sie und installiere die normale. Auch normale Versionen haben Bugs. Beta-Versionen tendenziell mehr. Aber zu dem Zeitpunkt, wenn eine neue Beta ausgerollt wird, kann ich auch nicht abschätzen, wie riskant das ist. Denn ich kann ja nicht vorhersagen, wie weit diese neue Beta jetzt von der nächsten Version entfernt ist, die wieder als „stabil“ gekennzeichnet werden wird.
Um mal deine Fragen zu beantworten:
- Die Anzahl kann ich dir natürlich nicht nennen. Komische Frage… Aber ich frage mich regelmäßig, z.B. wenn ich einen Bug finde, ob das aktuell eine Beta- oder eine Produktivversion ist. Das hat ja nichts damit zu tun, zu vergessen, ob man eine Beta installiert hat. Die App aktualisiert sich von allein und manchmal bekommt man eine Beta und manchmal nicht.
- Alle Beta-Nutzer. Wie eben beschrieben, werden auch Beta-Nutzer bei Verfügbarkeit auf die Release-Version umgestellt.
- Mein Problem ist, dass Vinz mir vermittelt hat, dass ich einen geschilderten Bug lieber in den Beta-Thread der aktuellen Version hätte packen sollen. Dann hab ich aber auf einmal erfahren, dass es aktuell gar keine Beta-Version gibt, und ich auf der Release-Version bin. Das ist mir aber nicht ersichtlich, wenn Betas nicht gekennzeichnet werden. Zusätzlich finde ich zumindest hier keine Threads mit den Release-Versionen. Nur solche mit Betas. Aber du kannst mich gern vom gegenteil überzeugen. Meinen Bug in der Release-Version soll ich dann also in den Beta-Thread packen? Das erscheint mir irgendwie unlogisch.
- Man muss ja nicht die Versionsnummer an sich verändern. Einfach in die App ein „B“ vor die Versionsnummer setzen oder so. Das ist dann lediglich die Kennzeichnung, dass die installierte Version eine Beta ist.
Und genau da kommen wir zu dem Hauptproblem: WOHER weiß ich, dass ich aktuell eine Beta-Version installiert habe? Ich habe ja keine Möglichkeit, das herauszufinden, weil die App darüber keine Information anzeigt.
Bedauerlicherweise ist genau das eben von den Appstore-Plattformen nicht vorgesehen. Hier hat sich Tomorrow ja schon geäußert.
Ich kenne mich hier bei Android zu wenig aus. Kann man nicht über den Playstore nachvollziehen, welche App dort als Produktionsfassung verfügbar ist?