[ English | Indonesia | русский | English (United Kingdom) | Deutsch ]

Rilis (release)

What is the OpenStack-Ansible release model?

OpenStack-Ansible uses the 'cycle-trailing' release model as specified in the OpenStack release model reference.

Bagaimana tag rilis diputuskan?

In order to ensure a common understanding of what release versions mean, we use Semantic Versioning 2.0.0 for versioning as a basis. The exception to the rule is for milestone releases during a development cycle, where releases are tagged <MAJOR>.0.0.0b<MILESTONE> where <MAJOR> is the next major release number, and <MILESTONE> is the milestone number.

The OpenStack series names are alphabetical, with each letter matched to a number (e.g., Austin = 1, Bexar = 2, Newton = 14, Pike = 16, etc.). OpenStack-Ansible adopted the same <MAJOR> release numbering as the Nova project to match the overall OpenStack series version numbering.

How frequently does OpenStack-Ansible release?

Major releases are done every six months according to the OpenStack release schedule. Each major release is consistent with an OpenStack series.

Rilis minor/patch diminta untuk cabang stabil pada hari Jumat kedua dan terakhir setiap bulan. Rilis biasanya selesai dalam beberapa hari setelah permintaan.

What version of OpenStack is deployed by OpenStack-Ansible?

For each OpenStack-Ansible release, the OpenStack version that is deployed is set to a specific OpenStack git SHA-1 hash (SHA). These are updated after every OpenStack-Ansible release. The intent is to ensure that OpenStack-Ansible users are able to enjoy an updated OpenStack environment with smaller increments of change than the typical upstream service releases allow for as they are usually very infrequent.

This does mean that a stable OpenStack-Ansible deployment will include a version of a service (e.g.: nova-17.0.3dev4) which does not match a tag exactly as you may expect (e.g.: nova-17.0.3).

Jika Anda ingin mengubah SHA ke SHA/tag/branch, tertentu, atau ingin menggunakan garpu sendiri (your own fork) dari layanan OpenStack, silakan lihat bagian berjudul Mengganti kode sumber proyek hulu (upstream) lainnya dalam buku petunjuk.

When does a patch to an OpenStack-Ansible role get into a release?

For each OpenStack-Ansible release, the Ansible roles that form that release are set to a specific git SHA-1 hash (SHA). These are updated after every OpenStack-Ansible release.

OpenStack-Ansible frequently does proactive bugfix backports. In order to reduce the risk of these backports introducing any destabilization, OpenStack-Ansible implements a 'soak' period for any patches implemented in the stable branches for roles, but also provides for circumventing this in exceptional circumstances.

Sebuah patch yang digabung menjadi sebuah role segera diuji oleh tes role lainnya, memastikan bahwa ada perubahan besar yang terjadi. Setelah rilis minor/patch diminta, build terintegrasi menerima patch 'SHA bump' untuk memperbarui build terintegrasi untuk menggunakan role terbaru yang tersedia termasuk patch baru itu. Set baru ini tersedia untuk pengujian kepada siapa saja yang ingin menggunakan kepala branch stabil (head of the stable branch), dan diuji dalam tes berkala hingga rilis berikutnya. Secara total, itu berarti bahwa waktu siklus untuk patch dari penggabungan hingga rilis adalah di mana saja dari dua minggu hingga satu bulan.

Jika ada persyaratan untuk menjalankan patch peran ke rilis berikutnya, maka siapa pun dapat mengusulkan perubahan ke file ansible-role-requirement.yml dalam repositori openstack/openstack-ansible dengan dengan justifikasi yang sesuai.

Kami percaya bahwa pendekatan ini membawa keseimbangan stabilitas yang masuk akal, sementara masih dapat melakukan backports pro-aktif.

The only exception to this process is for the master branch, which intentionally consumes the master branch from all roles between releases so that any changes are immediately integration tested.