Gibt es eine Spezifikation für die Förderung eines Release-Kandidaten?

Question

Ich frage mich, weil es mir gerade dämmerte, dass ich noch nie mit den bereitgestellten Release-Kandidatinnen in einem Unternehmen involviert war und ich sehe, dass der Begriff in diesen Tagen mehr und mehr verwendet wird, damit ich ein wenig klarer werden möchte über ihre Auswirkungen.

Für jeden, der tatsächlich für eine Firma gearbeitet hat, die RCs vorher zur Verfügung stellt ... gibt es zufällig irgendeine formellere Spezifikation dafür, was ein tatsächlicher Release-Kandidat mit sich bringt (wie der Unterschied zwischen einer RC und einer Beta) Ist es nur eine Politik, die jedes Unternehmen für sich selbst entscheidet?

Wenn Sie zufällig für eine Firma arbeiten, die diese Art von Spezifikation hat, könnten Sie vielleicht einige Beispiele für einige der Richtlinien, die es liest, eine Version zu "Release Candidate" fördern.

Answer 1

Ich habe das Wort RC auf zwei Arten verwendet gesehen:

1. Als eigentliche Release Candidate. Dies ist der Build, den wir an Kunden versenden werden, es sei denn, wir finden einen Showstopper. Es werden keine neuen Builds erstellt, bis ein größerer Bug gefunden wurde, dann wird ein neuer Build gesponnen und wir beginnen erneut. In der Regel gibt es zwischen 3-10 dieser Builds vor dem Versand.
2. Als "besser als Beta" Build. Es gibt keine Absicht, den Build tatsächlich zu verschicken, es ist nur ein Zwischenkontrollpunkt irgendwo zwischen Beta und Release. Typischerweise gibt es keine neuen Features über die Beta, nur Stabilität. So hat Microsoft in den letzten Jahren den Begriff Windows-Team verwendet (Windows 2000, Windows XP, Windows Vista).

Ich bevorzuge die erste Verwendung selbst. Es macht viel mehr Sinn.

Answer 2

Die klassische Definition eines Release-Kandidaten ist, dass es sich um die endgültige Version handeln könnte. Neue Builds würden nur erzeugt werden, wenn der Showstopper oder der Rückruf-Klassen-Bug gefunden würde.