[ English | Indonesia | 한국어 (대한민국) | English (United Kingdom) | русский | français | español | Deutsch ]
Rilis (release)¶
Apa model rilis OSA¶
OpenStack-Ansible (OSA) menggunakan model rilis 'cycle-trailing' seperti yang ditentukan dalam OpenStack release model reference_.
Bagaimana tag rilis diputuskan?¶
Untuk memastikan pemahaman umum tentang apa arti versi rilis, kami menggunakan Semantic Versioning 2.0.0_ untuk versi sebagai basis. Pengecualian untuk aturan ini adalah untuk rilis tonggak selama siklus pengembangan, di mana rilis diberi tag <MAJOR> .0.0.0b <MILESTONE>
di mana <MAJOR>
adalah nomor rilis utama berikutnya, dan <MILESTONE>
adalah angka tonggak sejarah.
Nama-nama seri OpenStack adalah abjad, dengan setiap huruf dicocokkan dengan nomor (misalnya: Austin = 1, Bexar = 2, Newton = 14, Pike = 16, dll). OSA mengadopsi penomoran rilis <MAJOR>
yang sama dengan proyek Nova untuk mencocokkan penomoran versi seri OpenStack secara keseluruhan.
Seberapa sering OSA rilis?¶
Rilis besar dilakukan setiap enam bulan sesuai dengan OpenStack release schedule_. Setiap rilis utama konsisten dengan seri OpenStack.
Rilis minor/patch diminta untuk cabang stabil pada hari Jumat kedua dan terakhir setiap bulan. Rilis biasanya selesai dalam beberapa hari setelah permintaan.
Versi OpenStack apa yang digunakan oleh OSA?¶
Untuk setiap rilis OSA, versi OpenStack yang digunakan diatur ke OpenStack specific git SHA-1 hash_ (SHA). Ini diperbarui setelah setiap rilis OSA. Tujuannya adalah untuk memastikan bahwa pengguna OSA dapat menikmati lingkungan OpenStack yang diperbarui dengan peningkatan perubahan yang lebih kecil daripada yang diizinkan oleh rilis layanan hulu karena mereka biasanya sangat jarang.
Ini berarti bahwa penyebaran OSA yang stabil akan mencakup versi layanan (misalnya: nova-17.0.3dev4) yang tidak cocok dengan tag persis seperti yang Anda harapkan (misalnya: 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.
Kapan patch ke peran OSA masuk ke rilis?¶
Untuk setiap rilis OSA, peran Ansible yang membentuk rilis tersebut diatur ke git SHA-1 hash_ (SHA) tertentu. Ini diperbarui setelah setiap rilis OSA.
OSA sering melakukan backports perbaikan bug pro-aktif. Untuk mengurangi risiko backport ini yang menyebabkan destabilisasi, OSA menerapkan periode 'soak' untuk setiap patch yang diterapkan di branch stabil untuk role, tetapi juga menyediakan untuk menghindari hal ini dalam keadaan luar biasa.
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.
Satu-satunya pengecualian untuk aturan ini adalah untuk branch master
, yang sengaja mengkonsumsi branch master
dari semua role di antara rilis sehingga setiap perubahan segera diuji integrasi.