ภาคผนวก G — Rust ถูกสร้างยังไงและ “Nightly Rust”
ภาคผนวกนี้เกี่ยวกับว่า Rust ถูกสร้างยังไงและนั่นกระทบคุณในฐานะนัก พัฒนา Rust ยังไง
Stability โดยไม่ Stagnation
ในฐานะภาษา Rust ใส่ใจ เยอะ เกี่ยวกับ stability ของโค้ดของคุณ เรา ต้องการให้ Rust เป็นพื้นฐานหินแข็งที่คุณ build บนได้ และถ้าสิ่งต่าง ๆ เปลี่ยนตลอด นั่นจะเป็นไปไม่ได้ ในเวลาเดียว ถ้าเราไม่สามารถ experiment กับฟีเจอร์ใหม่ เราอาจไม่ค้นพบข้อบกพร่องสำคัญจนกว่าหลัง release ของพวกมัน เมื่อเราไม่สามารถเปลี่ยนสิ่งอีก
วิธีแก้ของเราต่อปัญหานี้คือสิ่งที่เราเรียก “stability without stagnation” และหลักนำทางของเราคือ — คุณไม่ควรกลัวการ upgrade ไป version ใหม่ของ Rust stable การ upgrade แต่ละครั้งควรไม่เจ็บปวด แต่ ก็ควรนำคุณฟีเจอร์ใหม่ bug น้อยกว่า และเวลา compile เร็วกว่า
Choo, Choo! Release Channel และการขี่รถไฟ
การพัฒนา Rust ดำเนินบน ตาราง train นั่นคือ การพัฒนาทั้งหมดทำใน branch main ของ Rust repository Release ตาม model release train ของ ซอฟต์แวร์ ซึ่งใช้โดย Cisco IOS และ project ซอฟต์แวร์อื่น มีสาม release channel สำหรับ Rust:
- Nightly
- Beta
- Stable
นักพัฒนา Rust ส่วนใหญ่หลัก ๆ ใช้ stable channel แต่คนที่ต้องการลอง ฟีเจอร์ใหม่ experimental อาจใช้ nightly หรือ beta
นี่คือตัวอย่างของวิธีที่กระบวนการ development และ release ทำงาน — สมมุติว่า team Rust กำลังทำ release ของ Rust 1.5 release นั้นเกิดใน ธันวาคม 2015 แต่จะให้เราเลข version ที่เป็นจริง ฟีเจอร์ใหม่ถูกเพิ่ม ให้ Rust — commit ใหม่ลงบน branch main แต่ละคืน Rust version nightly ใหม่ถูกผลิต ทุกวันคือวัน release และ release เหล่านี้ถูกสร้างโดย infrastructure release ของเราอัตโนมัติ ดังนั้นเมื่อเวลาผ่าน release ของเราดูแบบนี้ ครั้งเดียวต่อคืน:
nightly: * - - * - - *
ทุกหกสัปดาห์ มันคือเวลาเตรียม release ใหม่! branch beta ของ Rust
repository แยกจาก branch main ที่ใช้โดย nightly ตอนนี้ มีสอง release:
nightly: * - - * - - *
|
beta: *
User Rust ส่วนใหญ่ไม่ใช้ beta release active แต่ test กับ beta ใน ระบบ CI ของพวกเขาเพื่อช่วย Rust ค้นพบ regression ที่เป็นไปได้ ใน ระหว่าง ยังมี release nightly ทุกคืน:
nightly: * - - * - - * - - * - - *
|
beta: *
สมมุติว่า regression ถูกพบ ดีที่เรามีเวลาบ้างในการ test release beta
ก่อน regression แอบเข้า stable release! Fix ถูก apply ให้ branch main
เพื่อให้ nightly ถูก fix และแล้ว fix ถูก backport ให้ branch beta
และ release ใหม่ของ beta ถูกผลิต:
nightly: * - - * - - * - - * - - * - - *
|
beta: * - - - - - - - - *
หกสัปดาห์หลังจาก beta แรกถูกสร้าง มันคือเวลาสำหรับ stable release!
branch stable ถูกผลิตจาก branch beta:
nightly: * - - * - - * - - * - - * - - * - * - *
|
beta: * - - - - - - - - *
|
stable: *
ไชโย! Rust 1.5 เสร็จ! อย่างไรก็ตาม เราลืมหนึ่งสิ่ง — เพราะหกสัปดาห์
ผ่านไป เรายังต้องการ beta ใหม่ของ version ถัดไป ของ Rust, 1.6
ดังนั้นหลัง stable แยกจาก beta, version ถัดไปของ beta แยกจาก
nightly อีก:
nightly: * - - * - - * - - * - - * - - * - * - *
| |
beta: * - - - - - - - - * *
|
stable: *
นี่ถูกเรียก “train model” เพราะทุกหกสัปดาห์ release “ออกจากสถานี” แต่ยังต้องเดินทางผ่าน beta channel ก่อนมันมาถึงเป็น stable release
Rust release ทุกหกสัปดาห์ เหมือนนาฬิกา ถ้าคุณรู้วันที่ของ Rust release หนึ่ง คุณรู้วันที่ของอันถัดไปได้ — มันคือหกสัปดาห์ภายหลัง แง่มุมดีของการมี release ตารางทุกหกสัปดาห์คือ train ถัดไปกำลังมาเร็ว ถ้าฟีเจอร์บังเอิญพลาด release เฉพาะ ไม่ต้องกังวล — อีกอันกำลังเกิดใน เวลาสั้น! นี่ช่วยลดความกดดันในการแอบฟีเจอร์ที่อาจไม่ขัดเงาใกล้ deadline release
ขอบคุณกระบวนการนี้ คุณ check build ถัดไปของ Rust และ verify ตัวเองได้
เสมอว่ามันง่ายที่จะ upgrade ไป — ถ้า beta release ไม่ทำงานตามคาด คุณ
รายงานให้ team และให้มันถูก fix ก่อน stable release ถัดไปเกิดได้!
Breakage ใน beta release ค่อนข้างหายาก แต่ rustc ยังเป็นชิ้นของ
ซอฟต์แวร์ และ bug มีอยู่
เวลา Maintenance
Project Rust สนับสนุน version stable ล่าสุด เมื่อ version stable ใหม่ ถูก release version เก่าถึง end of life (EOL) ของมัน นี่หมายความว่า แต่ละ version ถูกสนับสนุนเป็นเวลาหกสัปดาห์
ฟีเจอร์ Unstable
มีอีกหนึ่งจุดสนใจกับ release model นี้ — ฟีเจอร์ unstable Rust ใช้ เทคนิคเรียก “feature flag” เพื่อตัดสินว่าฟีเจอร์ใดถูกเปิดใน release ที่ให้ ถ้าฟีเจอร์ใหม่อยู่ภายใต้การพัฒนา active มันลงบน branch main และดังนั้น ใน nightly แต่หลัง feature flag ถ้าคุณ ในฐานะ user ต้องการลองฟีเจอร์ที่ work-in-progress คุณทำได้ แต่คุณต้องใช้ release nightly ของ Rust และ annotate source code ของคุณกับ flag เหมาะสมเพื่อ opt in
ถ้าคุณกำลังใช้ release beta หรือ stable ของ Rust คุณไม่สามารถใช้ feature flag ใด นี่คือ key ที่อนุญาตให้เราได้การใช้ practical กับ ฟีเจอร์ใหม่ก่อนเราประกาศพวกมัน stable ตลอดไป คนที่ต้องการ opt in ไป bleeding edge ทำได้ และคนที่ต้องการประสบการณ์หินแข็งติด stable และ รู้ว่าโค้ดของพวกเขาจะไม่ break ได้ Stability โดยไม่ stagnation
หนังสือนี้บรรจุเพียงข้อมูลเกี่ยวกับฟีเจอร์ stable เพราะฟีเจอร์ in-progress ยังเปลี่ยน และแน่นอนพวกมันจะต่างกันระหว่างเมื่อหนังสือนี้ ถูกเขียนและเมื่อพวกมันถูกเปิดใน stable build คุณค้นพบ documentation สำหรับฟีเจอร์ nightly-only online ได้
Rustup และบทบาทของ Rust Nightly
Rustup ทำให้ง่ายในการเปลี่ยนระหว่าง release channel ต่างกันของ Rust บนพื้นฐาน global หรือ per-project โดยค่าเริ่มต้น คุณจะมี stable Rust ติดตั้ง เพื่อติดตั้ง nightly ตัวอย่างเช่น:
$ rustup toolchain install nightly
คุณเห็น toolchain ทั้งหมด (release ของ Rust และ component
associate) ที่คุณติดตั้งกับ rustup ได้ด้วย นี่คือตัวอย่างบน
computer Windows ของหนึ่งใน author ของคุณ:
> rustup toolchain list
stable-x86_64-pc-windows-msvc (default)
beta-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc
ตามที่คุณเห็น toolchain stable คือ default User Rust ส่วนใหญ่ใช้
stable ส่วนใหญ่ของเวลา คุณอาจต้องการใช้ stable ส่วนใหญ่ของเวลา แต่
ใช้ nightly บน project เฉพาะ เพราะคุณใส่ใจเกี่ยวกับฟีเจอร์
cutting-edge เพื่อทำเช่นนั้น คุณใช้ rustup override ในไดเรกทอรีของ
project นั้นเพื่อตั้ง toolchain nightly เป็นอันที่ rustup ควรใช้
เมื่อคุณอยู่ในไดเรกทอรีนั้น:
$ cd ~/projects/needs-nightly
$ rustup override set nightly
ตอนนี้ ทุกครั้งที่คุณเรียก rustc หรือ cargo ภายในของ
~/projects/needs-nightly, rustup จะให้แน่ใจว่าคุณกำลังใช้ nightly
Rust แทน default ของคุณของ stable Rust นี่มีประโยชน์เมื่อคุณมี
project Rust เยอะ!
กระบวนการ RFC และ Team
แล้วคุณเรียนรู้เกี่ยวกับฟีเจอร์ใหม่เหล่านี้ยังไง? Model development ของ Rust ตาม กระบวนการ Request For Comments (RFC) ถ้าคุณต้องการการ ปรับปรุงใน Rust คุณเขียน proposal ที่เรียก RFC ได้
ใคร ๆ เขียน RFC เพื่อปรับปรุง Rust ได้ และ proposal ถูก review และ พูดคุยโดย team Rust ซึ่งประกอบด้วย subteam หัวข้อหลายตัว มี list เต็มของ team บน website ของ Rust ซึ่งรวม team สำหรับแต่ละพื้นที่ของ project — การออกแบบภาษา, implementation compiler, infrastructure, documentation และอื่น ๆ Team เหมาะสมอ่าน proposal และ comment เขียน comment ของพวกเขาเอง และ ในที่สุด มี consensus เพื่อยอมรับหรือปฏิเสธฟีเจอร์
ถ้าฟีเจอร์ถูกยอมรับ issue ถูกเปิดบน Rust repository และใครคนหนึ่ง implement มันได้ คนที่ implement มันอาจไม่ใช่คนที่เสนอฟีเจอร์ที่แรก เลย! เมื่อ implementation พร้อม มันลงบน branch main หลัง feature gate ตามที่เราพูดถึงในส่วน “ฟีเจอร์ Unstable”
หลังจากเวลาบ้าง เมื่อนักพัฒนา Rust ที่ใช้ release nightly ได้สามารถ ลองฟีเจอร์ใหม่ สมาชิก team จะพูดคุยฟีเจอร์ วิธีที่มันทำงานบน nightly และตัดสินว่ามันควรเข้า stable Rust หรือไม่ ถ้าการตัดสินคือเลื่อน ไปข้างหน้า feature gate ถูกลบ และฟีเจอร์ตอนนี้ถูกพิจารณา stable! มันขี่ train เข้าไปยัง stable release ใหม่ของ Rust