Einen Veröffentlichungszyklus mit einem Produkt machen, das über RPMs geliefert wird

Question

Ich habe gerade angefangen, mit einem Produkt zu arbeiten, das über den Linux-RPM-Mechanismus und nicht als eigenständiges Installationsprogramm geliefert wird, und erkannte, dass dies den Test/Release-Zyklus macht ein bisschen schwieriger.

Wenn ich mit Installateuren arbeitete, änderten wir einfach die Build-Nummerierung in unserem Build-System, um einen Build als Test- oder Release-Kandidat anstelle eines Entwicklungs-Snapshots zu markieren und den Leuten nur das zu testende Build zu übermitteln. Das Problem mit RPMs ist, dass wir, wenn wir das Nummerierungssystem ändern, den Liefermechanismus durchbrechen und installierte Maschinen nicht mehr erkennen können, welches die neueste Version des RPM ist.

Der beste Weg, um dies zu umgehen, ist, die Kandidaten-RPMs in ein komplett separates RPM-Repository zu legen, aber das wird auch kompliziert, weil wir mehrere RPMs aus demselben Repository haben, die sich in verschiedenen Release-Zyklen befinden Daher versuchen wir, die Release-Candidate-Version von RPM A aus dem neuen Repository zu holen, während wir weiterhin Entwicklungs-Snapshots von RPM B aus dem Entwicklungs-Repository abrufen möchten.

Dies muss ein ziemlich häufiges Problem für Linux-Software sein, also kann mir jemand die beste Praxis sagen? Vielen Dank im Voraus .....

Answer 1

Eine gängige Methode in der Linux-Welt ist eine weit verbreitete Veröffentlichungsnummernkonvention, die angibt, ob ein Build entwickelt oder veröffentlicht wird. Für den Linux-Kernel selbst sind Ungerade-Punkt-Versionen (2.5, 2.7) Entwicklung, während gerade (2.4, 2.6) Versionen sind.

Ein schneller Scan der RPM guide scheint darauf hinzuweisen, dass die Verwendung eines solchen Schemas die beste Wette ist.