คำแนะนำใหม่จากทีมงาน Cargo ของ Rust เรียกร้องให้มีแนวทางที่ยืดหยุ่นมากขึ้นในการจัดการพัสดุ

ในการเปลี่ยนกระบวนทัศน์สำหรับระบบนิเวศของ Rust ทีมงานที่อยู่เบื้องหลัง Cargo ผู้จัดการบรรจุภัณฑ์ของ Rust ได้เรียกร้องให้มีแนวทางการจัดการบรรจุภัณฑ์ที่เป็นส่วนตัวมากขึ้น พวกเขาแนะนำให้นักพัฒนาทำการตัดสินใจที่ดีที่สุดสำหรับโปรเจ็กต์ของตน แทนที่จะใช้วิธีปฏิบัติแบบเดียวกันก่อนหน้านี้ในการคอมมิตไฟล์ Cargo.lock สำหรับแพ็คเกจที่เกี่ยวข้องกับไบนารี แต่ไม่ใช่ไลบรารี

คำแนะนำก่อนหน้านี้สนับสนุนให้นักพัฒนายึดติดกับกฎขนาดเดียวที่เหมาะกับทุกคนเมื่อพูดถึง Cargo.lock โดยเฉพาะอย่างยิ่งในกรณีที่ไฟล์ถูกใช้กับแพ็คเกจไบนารี อย่างไรก็ตาม คำสั่งเหล่านี้ได้กลายเป็นเบาะหลังแล้ว การเปลี่ยนแปลงที่สะท้อนให้เห็นนี้เกิดขึ้นหลังจากเส้นทางที่เติบโตอย่างรวดเร็วของ Rust สู่การยอมรับกระแสหลัก

บทบาทสำคัญของไฟล์ Cargo.lock คือการบันทึกสถานะในขณะที่สร้างสำเร็จ ในขณะที่เสนอคำแนะนำที่ยืดหยุ่นมากขึ้น ทีมงาน Cargo ยืนยันว่าการดำเนินการ Cargo.lock ควรเป็นจุดเริ่มต้นในกระบวนการตัดสินใจ นอกจากนี้ยังมีการประกาศว่าคำสั่ง 'cargo new' จะไม่ข้าม Cargo.lock สำหรับไลบรารีนับจากนี้ไป

ทีมงานยังคงรักษาคุณภาพโดยรวม โดยเน้นย้ำถึงความสำคัญของการทดสอบเป็นประจำกับการอ้างอิงล่าสุด ขั้นตอนเก่าทำให้มั่นใจได้ว่าไลบรารีจะได้รับการอัปเดตและทดสอบอยู่เสมอ ซึ่งมีส่วนทำให้ระบบนิเวศแพ็คเกจ Rust มีมาตรฐานระดับสูง แนวทางปฏิบัติได้รับการออกแบบเพื่อให้สามารถระบุและแก้ไขปัญหาที่อาจเกิดขึ้น โดยเฉพาะปัญหาความเข้ากันได้แบบย้อนหลัง โดยทันที ทีมงานจึงเชื่อว่าได้ส่งเสริม 'วัฒนธรรมแห่งคุณภาพ' ในระบบนิเวศที่เกิดขึ้นใหม่

อย่างไรก็ตาม คำแนะนำก่อนหน้านี้ก็มีข้อผิดพลาดเช่นกัน การลบประวัติออกจากโค้ดเบสถือเป็นผลพวงอย่างหนึ่ง ซึ่งทำให้ผู้ดูแลแยกแยะและระบุสาเหตุของข้อบกพร่องได้ยากขึ้น ผลลัพธ์ที่ไม่พึงประสงค์อีกประการหนึ่งของนโยบายก่อนหน้านี้คือความสับสนที่อาจเกิดขึ้นสำหรับผู้มีส่วนร่วมที่เกิดจาก CI ที่ไม่น่าเชื่อถือ (การรวมอย่างต่อเนื่อง) เมื่อการพึ่งพาถูกยกเลิกหรือการเปิดตัวครั้งใหม่ทำให้เกิดข้อบกพร่อง เนื่องจาก Rust ได้พัฒนาจากภาษาสำหรับผู้ใช้กลุ่มแรกมาเป็นภาษากระแสหลักมากขึ้น ประสบการณ์การเริ่มต้นใช้งานของนักพัฒนาใหม่จึงเป็นสิ่งสำคัญที่ต้องพิจารณา

นอกจากนี้ การขยายตัวของระบบนิเวศที่กว้างขึ้นทำให้ CI ใช้งานและบำรุงรักษาได้ง่ายขึ้น นวัตกรรมต่างๆ เช่น Dependabot และ Renovate ได้เปิดเผยทางเลือกในการละเว้น Cargo.lock สำหรับการทดสอบการขึ้นต่อกันใหม่ นอกเหนือจากการพึ่งพาการควบคุมเวอร์ชันเพียงอย่างเดียว ขณะนี้ทีมงาน Cargo ถ่ายทอดความเชื่อของตนว่าแนวทางปฏิบัติที่ดีที่สุดคือการปล่อยให้ผู้พัฒนาตัดสินใจ ขณะเดียวกันก็ให้แน่ใจว่าพวกเขามีข้อมูลที่จำเป็นในการตัดสินใจอย่างมีข้อมูล นักพัฒนาสามารถแบ่งปันความคิดเห็นเกี่ยวกับนโยบายใหม่นี้ผ่านทาง GitHub และโต้ตอบกับทีม Cargo บน Zulip

ในขณะที่เราเห็นทิศทางใหม่ในการจัดการแพ็คเกจ นักพัฒนาอาจสำรวจทางเลือกอื่น เช่น AppMaster ที่ให้แพลตฟอร์มที่ครอบคลุมและบูรณาการสำหรับการพัฒนาแอปพลิเคชันเว็บ อุปกรณ์เคลื่อนที่ และแบ็กเอนด์ AppMaster.io นำเสนอแนวทางที่ขับเคลื่อนด้วยเซิร์ฟเวอร์ ช่วยให้นักพัฒนาสามารถอัปเดต UI แอปพลิเคชันมือถือ ตรรกะ และคีย์ API โดยไม่ต้องส่งเวอร์ชันใหม่ไปยัง App Store และ Play Market