Am Montag 14 Juli 2008 schrieb Dr. Ingo A. Wolf: > für mich von der Position als "außenstehender unwissender dummer > Laie" ist schwer verständlich und verwirrend, wieso man nicht (für > den Benutzer "draußen") einfach durchnummeriert. Das hätte den
Die Versionsnummern geben die Entwickler vor, wir als Packager können da nicht einfach hochnummerieren, denn wenn der Entwickler dann wirklich eine neue Version herausbringt, kämen wir in Konflikt mit deren Nummerierung. > Vorteil, dass man als Nicht-Entwickler-Insider (ich und viele andere > sind keine Profi-Programmierer) nicht sämtliche > Buchstabenkombinationen lernen und beherrschen muss > - (alpha, beta, cvs, a, b, svn, pm, rc, etc. ..... Das setzt aber voraus, dass die Entwickler halbwegs regelmäßig neue Versionen herausbringen, zumindest dann, wenn gravierende Probleme behoben werden. Ist das nicht der Fall, können wir als Packager dann entweder die ganzen Änderungen aus dem Entwicklerzweig in die letzte Version nachzupflegen, oder eben aus dem Entwicklerzweig (z.B. einem CVS) die Entwicklerversion selbst zu nehmen. In letzterem Fall hilft dann halt ein Kürzel hinter der Versionsnummer zur Unterscheidung. Im Fall der xine-ui liegt die letzte veröffentlichte Version eben schon mehr als ein Jahr zurück, wenn mir da ein Fehler gemeldet wird, der im Entwicklerzweig behoben wurde, neu Funktionen für die neuen libxine Versionen einzug gehalten haben, dann ist es meiner Meinung nach einfach sinnvoller den Entwicklerzweig direkt zu verwenden. > Dumme Frage: Heißt "pm" eigentlich Packman, Paketmanagement oder > persönliche Mitteilung oder etwas ganz anderes? Das Kürzel pm wurde eingeführt, um die Packman Pakete leichter von den anderen unterscheiden zu können. > Bei Google habe ich viele andere Bedeutungen für die Abkürzung "PM" > gefunden. PM wird als Abkürzung sicher vielfach verwendet. Ist aber sicher nicht anders wie mit z.B. md für die Mandriva Pakete. > Wäre, im Falle eines Falles, "CVS" oder "SVN", "PM" oder "b" oder "rc" > die neuere Version? CVS und SVN stammen aus dem aktuellen Entwicklerzweig, die Stabilität hängt von dessen Stand ab. Wenn ein Packager daraus ein Programm bastelt, muss er genau schauen, wie die Stabilität aussieht. Einige Projekte wie ffmpeg lassen uns dabei gar keine andere Wahl, als diesen Weg zu gehen, da über viele Jahre hinweg keine neuen Versionen mehr herausgebracht werden, die alten Versionen aber mit vielen anderen Programmen gar nicht nutzbar sind. Die alpha, beta und rc Versionen sind Snapshots von den Entwicklern, die in aufsteigender Reihenfolge an Stabilität zulegen sollten, rc (Release Candidate) sollte immerhin schon einer Endversion würdig sein. Sonstige Zusätze wie a, b, c oder so verwenden Entwickler oft, um Fehlerbereinigte Versionen eines Releases herauszubringen, die übernehmen wir einfach. > Und welche Version ist für mich als Benutzer die stabilste und somit > zu empfehlen? :-))-. Linux-Entwickler sind ja sonst bei der Immer die von Packman ;-) > Nummerierungslänge von Progammversionen nicht so sparsam, also z.B. > xine-ui 0.99.5.111111111.pm.0 oder xine-ui 0.99.5.012345.pm.12345. > Ich weiß allerdings nicht, was dabei noch alles zu beachten ist, damit > YaST das richtig erkennt oder welche Konventionen der > Linux-Entwicklergemeinde da nun wieder verletzt würden. Naja, die Versionsnummernvergabe ist ja nicht normiert, weder in der Linux-Gemeinde, noch sonstwo (3.1, 95, 98, NT, ME, 2000, XP, 2003 und Vista ist auch nicht unbedingt einleuchtend). Bei RPMs gibt es in jedem Fall immer eine Versions und eine Build Nummer. Die Versionsnummer wird normalerweise vom Entwickler übernommen, die Build-Nummer ist dann mit einem Bindestrich abgetrennt und wird von uns eben mit dem .pm. versehen und mit jedem Build hochgesetzt um mit der selben Version immer wieder neue Pakete anbieten zu können. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ Manfred | http://packman.links2linux.de/ _______________________________________________ Packman mailing list [email protected] http://212.112.227.138/cgi-bin/mailman/listinfo/packman
