Die Programmiersprache Ruby

Blog| Forum| Wiki  

Die Versionierung von Ruby und Zusatzsoftware wie RubyGems erfolgt meist nach einem bestimmten Schema. Dieses möchte dieser Artkikel näher erklären.

Inhaltsverzeichnis

Versionierung von Gems

Klassischerweise sind Gems in der Form major.minor.tiny versioniert, also in drei Teilen. Die Bedeutung der einzelnen Versionsnummern ist dabei üblicherweise wie folgt:

  • major: Diese Zahl wird nur angehoben, wenn sich tiefgreifende, strukturelle Änderungen in einer Programmbibliothek ereignet haben. Code, der für vorhergehende Versionen geschrieben wurde, ist nicht mehr kompatibel mit der neuen Version.
  • minor: Neue Features wurden hinzugefügt und/oder alte entfernt. Für vorangehende Versionen geschriebener Code kann kompatibel sein, muss es aber nicht zwangsläufig.
  • tiny: Bei Bugfixes und/oder Schönheitskorrekturen wird diese Zahl erhöht. Für vorangehende Versionen geschriebener Code sollte kompatibel sein.

Jede dieser Zahlen kann dabei auch mehrstellig so, sodass nicht nach 0.1.9 zwangsläufig 0.2.0 kommen muss. 0.1.10 wäre ebenfalls möglich.

Prerelease-Versionen

RubyGems erlaubt den Zusatz eines vierten Bestandteils an die Versionsnummer, sodass z.B. 0.1.0.beta2 oder 0.1.0.rc1 entstehen. Solche Versionsnummern nennt man Prerelease-Versionen (engl. "Vor der (Haupt-)Veröffentlichung") und sie erlauben es engagierten Testern, kommende Versionen von Gems zu testen, ohne das bestehende stabile Release zu überschreiben. Nehmen wir an, auf dem RubyGems-Index wären die folgenden Gems registriert:

  • mein_gem 0.0.13
  • mein_gem 0.1.0.beta4

Führt jemand nun gem install mein_gem aus, wird ihm die Version 0.0.13 installiert, obwohl eine neuere theoretisch verfügbar wäre. Um die Beta-Version zu bekommen, muss er RubyGems entsprechend instruieren: gem install mein_gem --pre. Gleiches gilt selbstverständlich für gem update.

Rubys Versionierung

Ruby selbst folgt einem ähnlichen, aber nicht gleichen Schema. Üblicherweise sieht eine Ruby-Versionsnummer so aus:
1.9.2p0 (2010-08-18 revision 29036). Sie gliedert sich in 5 Bestandteile:

  • major (1): Wird nur bei tiefen strukturellen Änderungen erhöht.
  • minor (9): Wird bei Änderungen am API erhöht.
  • tiny (2): Wichtige Releases, die eventuell etwas am API ändern, es aber nicht müssen, erhöhen diese Zahl.
  • patchlevel (p0): Urspünglich bezeichnete das Patchlevel die Anzahl an Patches, die in den Interpreter eingeflossen waren, heute handelt es sich hierbei nur noch um eine grobe Richtlinie. Entspricht etwa der Anzahl an Bugfixes, die gemacht wurden.
  • SVN-Revision (29036): Die SVN-Revisionsnummer, aus der ein Interpreter ausgecheckt wurde. Dazu gehört ebenfalls das Datum, an dem die Revision ausgecheckt wurde, im Format Jahr-Monat-Tag. Im Beispiel wurde also die Revision 29.036 am 18. August 2010 ausgecheckt.

Siehe auch