Magento 2: วิธีการระบุ“ Semantic Versioning” Dependencies ในโมดูลของผู้แต่งของฉัน

การพัฒนาและการปรับใช้ของ Magento 2 รวมถึงกระบวนการอย่างเป็นทางการสำหรับการกำหนดเวอร์ชันซึ่งโมดูลหลักของระบบวีโอไอพีรุ่นหลักและรุ่นรองจะถูกชนตามการเปลี่ยนแปลงในคุณสมบัติที่เข้ากันได้แบบย้อนหลัง

ในฐานะนักพัฒนาโมดูล Magento ฉันจะสร้างรายการข้อกำหนดในไฟล์ composer.json ของฉันเองได้อย่างไร ฉันต้องดูโมดูลของฉันด้วยตนเองทุกครั้งที่ฉันใช้โค้ดหลักของวีโอไอพีและเพิ่มrequire:...บรรทัดใน composer.json หรือไม่ หรือมีเครื่องมืออัตโนมัติที่สามารถทำได้สำหรับฉัน

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

มีคำอธิบายระดับสูงจำนวนมากของคุณลักษณะนี้ที่ลอยอยู่รอบ ๆ - แต่ก็ไม่ชัดเจนว่าขั้นตอนการปฏิบัติที่นักพัฒนาควรจะทำคืออะไรและ / หรือผลที่แท้จริงของขั้นตอนเหล่านั้นคืออะไร

ฉันต้องดูโมดูลของฉันด้วยตนเองทุกครั้งที่ใช้รหัสหลักของวีโอไอพีและเพิ่มความต้องการ: ... line to composer.json?

ใช่ทุกครั้งในรหัสของคุณคุณใช้อะไรจากโมดูลหลักที่คุณต้องการเพิ่มลงในความต้องการของนักแต่งเพลงของคุณ ตามที่คุณต้องการให้โหลดคำสั่งของคุณอยู่หลังโมดูลหลักฉันขอแนะนำให้เพิ่มลงmodule.xmlในไฟล์ของคุณในส่วนลำดับ

หรือมีเครื่องมืออัตโนมัติที่สามารถทำได้สำหรับฉัน

ฉันยังไม่เจอเลย หากมีโปรดแจ้งให้เราทราบ มันจะต้องเป็นเครื่องมือที่มีความซับซ้อนพอสมควรและอาจต้องใช้การทดสอบที่ครอบคลุมแล้วจึงเรียกใช้เมทริกซ์รุ่นต่าง ๆ เพื่อสร้างชุดการทำงาน

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

ตัวเลือกเพื่อกำหนดหมายเลขรุ่น

1. 100.0.2
   ใช้งานได้เฉพาะรุ่นที่ระบุนี้เท่านั้น

2. 100.0.*
*เป็นตัวแทนและสามารถถูกแทนที่ด้วยหมายเลขรุ่นใด ๆ 100.0.0, 100.0.1, ...,100.0.120

3. ~100.0.2
   ทำให้ 2 สัญลักษณ์ตัวแทนที่สามารถขึ้นไปดังนั้น100.0.2, 100.0.3, ...,100.0.120

4. ^100.0.2
   อนุญาตใด ๆ ที่ปล่อยขึ้นไปจนถึง 101 ดังนั้น100.0.2, 100.0.3, ..., 100.1.0,100.2.5

สำหรับตัวเลือก 2-4 หากการตั้งค่าความเสถียรของคุณอนุญาต 100.0.1-beta

การใช้งานจริง

ตัวเลือกที่ 1) เป็นรูปแบบที่ระมัดระวังที่สุดคุณรู้ว่ารุ่นใดที่คุณพัฒนาและยอมรับเฉพาะการทำงานกับรุ่นนี้เท่านั้น - โมดูลของคุณสามารถติดตั้งพร้อมกับโมดูลนั้นในรุ่นนั้นได้ ความพยายามในการติดตั้ง / อัปเกรดอื่น ๆ ทั้งหมดจะล้มเหลวพร้อมกับข้อความของผู้แต่งที่เน้นว่าไม่สามารถหาชุดของส่วนประกอบที่ติดตั้งได้

ตัวเลือกที่ 2) ฉันคิดว่าสามารถคิดว่าไม่ใช่ตัวเลือกตามที่ครอบคลุมโดยตัวเลือก 3) ถ้าคุณใช้มันชอบ ~100.0.0

ตัวเลือกที่ 3) เข้ากันได้ตราบใดที่ไม่มีคุณสมบัติใหม่ ๆ

ตัวเลือกที่ 4) เข้ากันได้ตราบใดที่ไม่มีการเปลี่ยนแปลงที่ทำให้แตกหัก

การแลกเปลี่ยน

1 ส่วนขยายของคุณใช้งานได้กับโมดูล Magento 1 รุ่นเท่านั้น (โดยทางเทคนิคหากไม่มีการเปลี่ยนแปลงใด ๆ ในโมดูลหมายเลขรุ่นไม่ควรเพิ่มขึ้นและรุ่น Magento Project หลาย ๆ ทฤษฎีอาจรวมโมดูล Magento core เดียวกันกับรุ่นเดียวกันในทางปฏิบัติ ไม่ได้เห็นสิ่งนี้และดูเหมือนว่ามันต้องมีการเปลี่ยนแปลงกระบวนการบางอย่างในปลายวีโอไอพีดูที่นี่) เนื่องจากคุณเชื่อมโยงอย่างใกล้ชิดกับโมดูลหลัก 1 เวอร์ชันของ Magento คุณจึงมีการเผยแพร่และรุ่นส่วนขยายของคุณเองมากมายหากคุณต้องการใช้งานร่วมกันได้

3-4 ส่วนขยายของคุณใช้งานได้กับ Magento หลายรุ่นและคุณไม่จำเป็นต้องปล่อยส่วนเสริมที่แตกต่างกันทุกครั้งที่ Magento ออกรุ่นใหม่ ข้อเสียของที่นี่คือคุณอ้างสิทธิ์ในการใช้งานร่วมกันได้แม้ว่าจะมีการเปลี่ยนแปลงใน Magento ที่เข้ากันไม่ได้กับรหัสของคุณเอง ความเสี่ยงนี้เป็นจริงเนื่องจากการกำหนดเวอร์ชันแบบ semantic ของวีโอไอพีสำหรับโมดูลของตัวเองนั้นจะครอบคลุมเฉพาะสิ่งที่มีการทำเครื่องหมายกำกับไว้เท่านั้น@api(เพิ่มเติมเกี่ยวกับเรื่องนี้ในปัญหา GitHub นี้ ) ที่มีขอบเขต จำกัด

TL; DR;
100.0.2เล่นอย่างปลอดภัยรีลีสจำนวนมากเพื่อรักษา
^100.0.2เวอร์ชันเซมิคแบบที่คุณควรใช้งานปล่อยให้คุณน้อยลง แต่มีความเสี่ยงสูงขึ้นเนื่องจากในปัจจุบันมีขอบเขต จำกัด ของ@apiคลาสและวิธีการที่มีคำอธิบายประกอบ หากคุณมีส่วนขยายซึ่งเป็น 100% โดยใช้คลาสที่ถูกทำนองคลองธรรมและวิธีการนี้จะเป็นตัวเลือกที่ชัดเจน

อาจเป็นไป0.1.0-alpha1 -> 0.1.0-alpha2, 0.1.0-alpha3,ตามความเสถียรของโมดูล ตามที่แชร์ในเอกสารข้อกำหนดจะมีลักษณะดังนี้: -

"require": {
    "myexamplestore/product-bundle": "2.0.0-RC1",
    "myexamplestore/acme-extension": "~1.0"
    }

จากการอัพเดทของคุณสิ่งนี้ควรได้รับการอัพเดตเช่น: -

"require": {
    "myexamplestore/product-bundle": "2.4.0-RC1",
    "myexamplestore/acme-extension": "~2.0"
    }

ฉันไม่คิดว่าจะมีระบบอัตโนมัติใด ๆ สำหรับเรื่องนี้ แต่ตามเอกสารมันสำคัญมากที่จะทำตามนี้

แต่คุณควรใช้ PATCH หากมีการแก้ไขข้อบกพร่องเล็กน้อยในโมดูลของคุณ

อ้างถึง

PATCH บ่งชี้การแก้ไขข้อบกพร่องที่เข้ากันได้ย้อนหลัง

คุณถูกต้องคำตอบนั้นไม่ชัดเจนนัก แต่คุณจะเห็นว่ามันได้รับการปรับปรุงย้อนหลังไปประมาณ 1 ปี แต่นี่เป็นวิธีการ