Rilis

[ English | Deutsch | 中文 (简体, 中国) | español (México) | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]

Rilis

OpenStack memiliki irama (cadence0 rilis selama 6 bulan dengan model rilis berbeda yang dapat dipilih proyek untuk diikuti.

Bagian ini memungkinkan Anda untuk:

  • Memahami berbagai model rilis yang diikuti oleh komponen OpenStack

  • Ketahui struktur dari model rilis yang berbeda dan cara bekerja secara efektif pada mereka untuk mempengaruhi masa depan OpenStack

Model Rilis

OpenStack terdiri dari sejumlah besar proyek yang membentuk komponen utama dari cloud OpenStack, dari pustaka klien hingga layanan manajemen siklus hidup. Berbagai proyek berbeda di alam yang menyiratkan berbeda release models mengikuti.

Opsi yang saat ini tersedia adalah sebagai berikut:

Jadwal dan Perencanaan Rilis

Sebagian besar proyek OpenStack resmi mengikuti jadwal rilis yang ditetapkan oleh Release Management Team.

Siklus 6 bulan dibagi menjadi tiga tonggak dan periode stabilisasi yang biasanya satu bulan dengan kandidat pelepas.

Periode pertama siklus mencakup lebih banyak fokus pada perencanaan, itulah sebabnya PTG dijadwalkan tepat setelah rilis. Ini adalah fase ketika Anda harus mengunggah spesifikasi Anda untuk ditinjau dan menggunakan milis, saluran proyek, dan pertemuan di IRC untuk membahas bagian mana pun dari desain Anda yang mungkin dipertanyakan.

Setelah tonggak pertama, beberapa proyek lebih fokus pada pengembangan dan kegiatan perbaikan bug, sementara proyek lain mungkin masih menerima ide-ide baru untuk diimplementasikan dalam siklus itu.

Periode ketiga rilis berfokus pada penyelesaian implementasi dan pengujian fungsionalitas baru yang ditambahkan selama rilis. Anda perlu memastikan untuk menambahkan tes baru di Tempest dan memiliki dokumentasi yang tercakup juga sebelum tonggak ketiga. Selama fase ini tim peninjau inti dapat memilih untuk fokus hanya pada fitur-fitur prioritas tinggi. Mereka membuat keputusan tentang prioritas baik di PTG atau segera setelah itu, beberapa saat sebelum tonggak pertama rilis.

Beberapa proyek juga memiliki tanggal yang berbeda melalui siklus rilis sebagai tenggat waktu internal dan spesifik proyek, seperti pembekuan spesifikasi atau pembekuan kode. Anda harus memastikan bahwa Anda mengetahui tanggal pembekuan yang dapat Anda temukan di halaman jadwal rilis <https://releases.openstack.org>`_.

Setelah tonggak ketiga, komunitas fokus pada menstabilkan rilis dengan lebih menekankan pengujian dan memperbaiki bug. Proyek-proyek setelah siklus rilis memiliki calon rilis mereka ditandai setelah tonggak ketiga. Tidak ada batasan untuk melepaskan kandidat, tetapi tujuannya adalah untuk menjaga jumlah yang rendah dan memperbaiki semua masalah kritis yang diidentifikasi oleh tonggak-3.

Memiliki proyek utama setelah siklus rilis memastikan bahwa semua proyek ini dirilis pada waktu yang sama sehingga ini dapat diambil oleh tim hilir untuk dipaket dan didistribusikan lebih lanjut.

Stable Branches

Once a 6-month development cycle is completed the code for that release is branched, in git, to a stable branch. For instance, when the Stein release was completed a new branch in git, stable/stein was created.

Stable branches are kept as a safe source of fixes for high impact bugs and security issues which have been fixed, on master, since the release occurred. Given the stable nature of these branches, backports to stable branches undergo additional scrutiny when they are proposed. Proposed changes should:

  • Have a low risk of introducing a regression

  • Have a user visible benefit

  • Be self contained

  • Be included in master and backported to all releases between master and the stable branch in question

Project teams do point releases off stable branches when enough changes accumulate in the stable branch to justify creating another release for their project.

Stable branches proceed through different levels of maintenance as they age.

State

Time frame

Summary

Maintained

Approximately 18 months

All appropriate bug fixes accepted and releases are produced.

Extended Maintenance

While there are community members maintaining it.

All appropriate bug fixes accepted. No releases are produced and there is reduced CI commitment.

Unmaintained

6 months from the time the branch is made unmaintained.

The branch is under Extended Maintenance rules, but there are no maintainers.

End of Life (EOL)

N/A

Branch is no longer accepting Changes.

Before the Ocata release the Maintained and Extended Maintenance phases were only 6 months long. This meant that each release went End of Life after 18 months. It was determined that this practice was not beneficial for distributors or users of OpenStack. As a result the Maintained state was updated to last 18 months and the Extended Maitenance time frame was made flexible increasing the number of stable branches still accepting fixes.

The state of all OpenStack releases may be seen on the OpenStack Releases web page.

For more detailed information on Stable Branches and their maintenance phases see the Stable Branches page.

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.