• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

[DEV] Automatischer Check auf neue Version

pfeffer

Geowizard
Hi!

Der automatische Check auf neue Version funktioniert derzeit nicht. Das würde ich gern für die 1.0 noch richtig machen.
Weil dies eine Funktion ist, die über viele Versionen hinweg funktionieren soll, sollten wir uns ein paar Gedanken dazu machen.

Meine erste Idee war, die SVN-Revision zu vergleichen. Das wäre aber in dem Sinne nicht dauerhaft, da es nicht auszuschließen ist, dass wir irgendwann das SVN-Repository wechseln. Deswegen kommt nur eine manuelle Lösung in betracht. Am liebsten wäre mir dabei, wir würden den angezeigten Versionsstring als Vergleich verwenden. Dabei stellt sich allerdings das Problem, ein "größerer" String nicht immer auch eine neuere Version angibt. "1.0 RC 1" ist beispielsweise größer als "1.0", aber 1.0 ist die neuere.

Oder sollen wir die 1.0 RC 1 einfach 0.9p1 nennen?

Oder machen wir eine Kombination aus manuell und SVN-Nummer, etwa so:
1.0 1164 Das erscheint mir im Moment das beste. Bei einem Umstieg auf ein neues SVN-Repository können wir dann die manuelle Nummer erhöhen und schon wird alles als neuer eingestuft, auch wenn die SVN-Nummer kleiner ist. Evtl. machen wir noch eine zusätzlich Ziffer dazwischen, damit ein SVN-Repository-Wechsel nicht eine Erhöhung der angezeigten Version zur Folge haben muss. Mein Vorschlag wäre, also folgendes Format:

1.0 0 1164
allegmein:
[angezeigte Version][leertaste][manueller Repository Zähler][leertaste][SVN-Revision]

Dann wäre noch die Frage zu klären, wo das Textfile hin soll, dass diesen String enthält. Damit wir bei einem Repository-Wechsel keine Probleme bekommen, schalge ich vor, dazu eine wahrscheinlich konstantere URL zu nehmen. Am liebsten wäre mir in einer Domäne cachewolf.org. Könnte die jemand anlegen?

Was haltet Ihr davon?

Schöne Grüße,
Pfeffer.
 

TweetyHH

Geomaster
Diesen langen String finde ich aus verschiedenen Gründen nicht so günstig. Ich würde einfach die SVN Nummer nehmen. Selbst wenn man das SVN Wechselt, sollte man ja die alte History mitnehmen. Dadurch ist für jeden ziemlich schnell ersichtlich auf welcher Version er arbeitet.

Technisch würde ich soweit gehen, dass auf einem Server, der möglichst stabiel bleibt, 2 Dateien liegen: "Release" und "Beta" (meinetwegen auch 3, und wenn man Beta != nightlyBuild haben möchte).
Die Dateien könnten dann wie folgt aussehen:
Code:
1156
Version 1.0
http://www.server.de/cachewolf/1156/
1. Zeile einfach die aktuelle Versionnummer
2. Zeile eine Menschlich lesbare Versionsnummer. Kann auch gerne weggelassen werden, dann müssten die Leute sich nur daran gewöhnen, dass das Programm "nummiert" wird.
3. Zeile Die Adresse des Servers, wo sich die Dateien befinden, damit ein Serverumzug für die größeren Dateien leicht von statten geht, falls mal zuviel Traffic anfallen sollte.

Durch ein Skript würde die Beta datei nach jedem neuen bauen der Nightly-Build version angepasst werden und die Release Version müsste dann händisch gepflegt werden. Und im Cachewolf halt als Option den Butzern umstellen lassen ob er Release oder Beta haben möchte. Toll wäre es, wenn es klappen würde, dass ein automatisches Downloading und ersetzen der Version funktioniert.

just my 2 cent

Grüße Florian

P.S. Und insgesamt würde ich vorschlagen, dass man alle vielleicht 50 SVN versionen checkt ob es sehr arge Mängel gibt, die dagegen sprechen, dass eine Version genutzt wird und die dann in Releasen: Also z.B. bei 1200 eine woche darauf gucken ob hier massive Mängel auftreten und dann releasen. Momentan scheint es ja nur wenig Bugs zu geben, die nicht sehr schnell jemandem auffallen.
 

greiol

Geoguru
wie wärs denn mit dem major.minor.release schema. alternativ könntet ihr euch mal anschauen wie beispielsweise bei .rpm oder .deb softwarepaketen versionen verglichen werden. man muss da ja kein neues rad bauen.
 
OP
pfeffer

pfeffer

Geowizard
ok, wir sind da ja gar nicht so weit auseinander. Was Du in eine extra Zeile schreiben wolltest, hatte ich halt mit Leertaste getrennt.
Ich werde es dann so machen:
---
SvnRevision: 12345
MajorSvn: 0
FriendlyVersion: 1.0 RC 1
---
In einer späteren Version können dann weitere Tags definiert werden, mit deren Hilfe ein automatisches Update möglich wird.

CacheWolf wird von http://www.cachewolf.de/currentrelease.ver dieses File zu holen versuchen. Dort sollte dann ein HTTP-Redirect auf ein File currentrelease.ver im SVN verweisen. Auf diese Weise kann es leicht gepflegt werden und ist grundsätzlich unabhängig von SVN-Repository.

Ich würde vorschlagen, dass es ein weiteres File geben wird mit den entsprechenden Daten für die aktuelle Beta.

Vielleicht macht man auch ein "master" File, dass als Tags die Links zu den jeweiligen Dateien mit den Versionsinformationen enthält. Dann können wir noch flexibler sein und Nightly Builds, Betas und Releases anbieten und was wir davon anbieten auch später noch ändern.

Was meint Ihr?

@Greiol: könntest Du uns erklären wir das apt macht?

Schöne Grüße,
Pfeffer.
Gruß,
Pfeffer.
 

MiK

Geoguru
Wegen einem möglichen Umzugs des SVN brauchen wir keine extra Nummer einführen. Zum einen kann man das komplette SVN auf einen anderen Server übertragen. Zum anderen kann man zur Not die Revisonsnummern mit einem Skript wieder hochzählen.
 
OP
pfeffer

pfeffer

Geowizard
aber es schadet auch nicht, oder?
Irgendwie ist mir wohler, wenn wir noch eine manuelle Eingriffsmöglichkeit haben.

Gruß,
Pfeffer.
 

MiK

Geoguru
Ich halte es für überflüssig und verwirrend eine Reposity-Nummer zu führen. Das macht kein anderes Projekt. Wenn wirklich die Revisionsnummer nicht beibehalten könnten (halte ich für ausgeschlossen, da man sie ja wie gesagt auch zur Not einfach mit dummy-Commits hochtreiben kann), können wir immer noch die Versionsnummer ändern.

Ich bin deswegen für eine eindeutige Nummer der Form: Major.Minor.SVN-Revision.

Zusätzlich können Releases (alles außer NBs) noch einen Namen bekommen, in dem dann auch Sachen wie "beta", "BE", "RC" auftauchen können, ohne den Versionscheck zu beeinflussen.
 
OP
pfeffer

pfeffer

Geowizard
achso.
Ich wollte nur SVN-Revision vergleichen, nicht jedoch die Versionsnummer. Das würde aber bedeuten, dass wir keinerlei manuelle Eingriffsmöglichkeit hätten. Und deswegen wollte ich der SVN-Revisionsnummer noch etwas voranstellen: MajorSvn.

In Deiner Variante müsste konsequenterweise die SVN-Revision auf Null gesetzt werden, wenn die Versionsnummer erhöht wird.

Ich programmiere das grad: auf #cachewolf weiter diskutieren?

Gruß,
Pfeffer.
 

MiK

Geoguru
Nein. Die SVN-Nummer muss deswegen nicht auf 0 gesetzt werden. Man muss eben nur wissen, was die dritte Zahl bedeutet. In anderen Projekten steht dort einfach die Buildnummer. Die wird auch nicht auf 0 gesetzt, wenn sich etwas an der Minor-Version ändert.

(Habe leider jetzt erstmal ein paar Stunden keine Zeit für IRC.)
 
OP
pfeffer

pfeffer

Geowizard
ok, dann mache ich es so:
major.minor.svn

Die Buchstaben hinter der Versionsnummer ("0.9n") werden damit abgeschafft und durch eine einfache Nummerierung ersetzt.

Dabei mache ich 4 version-types:
0: "Release"
1: "Release Candidate",
2: "in development, stable",
3: "in development, newest"


Ich denke, ich mache zusätzlich ein Feld: RecommendedVersionType

Ist's so in Ordnung?

Gruß,
Pfeffer.
 

MiK

Geoguru
Wie genau hast Du dir das mit dem version-type und RecommendedVersionType vorgestellt. Wie und wo werden die verwendet?
 
OP
pfeffer

pfeffer

Geowizard
jeder Versionstyp bekommt eine eigene Datei, mit den Versionsinfos im SVN.
außerdem gibt es eine Verweisdatei, die die Links zu diesen Dateien und die angabe, wleches der recomenndentype ist, enthält.
von http://www.cachewolf.de/currentversion.txt wird auf diese Datei am liebten per http-redirect verwiesen.

Beim prüfen auf neue Version, werden alle Versionen gecheckt und angezeigt, ob im Vergelich zur verwendeten, es ein update gibt.

An den Versionstypen, die recommended ist, kommt ein Hinweis dran, dass das die empfohlene Version ist.

Also: wenn 1.0 RC 1 erscheint, dann steht recommendedtype auf "ReleaseCandidate", wenn 1.0 dann erschienen ist, dann steht recommendedtype auf "Release". Wenn irgendwann die Release kaum noch zu gebrauchen ist, es aber noch kein neues Release gibt, dann stellen wir Recommendedtype auf "InDevelopmentStable" oder so.

Was haltet Ihr davon?

Gruß,
Pfeffer.
 
OP
pfeffer

pfeffer

Geowizard
Vorab:
ich möchte das hier möglichst gründlich diskutieren, weil man einen automatsichen Versionscheck später kaum noch ändern kann.

ich habe es jetzt (SVN 1173) so gemacht, dass die Versionen alle in einem File beschrieben werden.

Inhalt:
---
# Release
T0VersionMajor: 0
T0VersionMinor: 9
T0Revision: 0

# ReleaseCandidate
T1VersionMajor: 0
T1VersionMinor: 9
T1SvnRevision: 800

# InDevelopmentStable
T2VersionMajor: 0
T2VersionMinor: 9
T2SvnRevision: 1000

# InDevelopmentNewest
T3VersionMajor: 1
T3VersionMinor: 0
T3SvnRevision: http://flyingfish...

RecommendedType: 3
---
Wenn bei SvnRevision der Wert mit "http" beginnt, dann wird die URL geöffnet und darin nach "Revision: nnnn" gesucht und nnnn als SvnRevision verwendet. Dieser Trick macht es möglich, dass wir immer auf die neueste Build auf flyingfish referenzieren können.

a) Was haltet Ihr von diesem Verfahren?

b) Jetzt muss endgültig geklärt werden, wie URL sein soll, die auf die currenversions.txt im svn verweist. Dazu ein paar Überlegungen.
Dieser Link muss so stabil wie möglich sein. Am liebsten wäre mir deshalb http://www.cachewolf.org/currentversions.txt, weil ich dafür bin, in Zukunft auch diesen DNS zu registrieren, denn CacheWolf wird in immer mehr Sprachen verfügbar. Das würde bedeuten, vor der 1. Release müsste diese Domain angelegt werden. Kann das jemand machen?
Andererseits muss für die Programmierer eine Möglichkeit bestehen, diesen Verweis zu ändern. Wenn der Verweis nicht innerhalb des wikis liegt, kann das nur derjenige machen, der root-zugriff auf die cachewolf-webpage hat. Deshalb könnte man überlegen eine Verweisdatei innerhalb des wikis anzulegen. Aber dann hat er keine schöne URL und wenn wir auf einen anderen Wiki umsteigen, bekommen wir Probleme.

Insgesamt wäre damit ein Vorschlag:
Irgendjemand registriert http://www.cachewolf.org und erteilt 2 aktiven Programmieren root-Zugriffsrechte. Der Einfachheit halber würde ich auf .org zunächst nur eine Weiterleitung nach .de einrichten und dort currentversions.txt hinterlegen.

Was haltet Ihr davon?

c) wer hat im Moment die Möglichkeit, http://www.cachewolf.de zu ändern und dort den verweis auf currentversion.txt zu hinterlegen?

Gruß,
Pfeffer.
 
Oben