Magento 2: Cách chỉ định phụ thuộc phiên bản ngữ nghĩa của vùng Viking trong composer.json của mô-đun của tôi

Sự phát triển và triển khai của Magento 2 bao gồm một quy trình chính thức để tạo phiên bản , trong đó các phiên bản chính và phụ của các mô-đun Magento lõi sẽ được nâng cấp dựa trên những thay đổi trong các tính năng tương thích ngược.

Làm thế nào tôi, với tư cách là nhà phát triển mô-đun Magento, xây dựng một danh sách các yêu cầu trong tệp composer.json của riêng tôi? Tôi có cần phải xem thủ công mô-đun của mình mỗi khi tôi sử dụng một đoạn mã Magento lõi và thêm một require:...dòng vào composer.json không? Hoặc có một công cụ tự động có thể làm điều đó cho tôi?

Làm cách nào để chỉ định một phiên bản để đưa vào composer.json? Nó có nên là phiên bản mô-đun cụ thể mà tôi đã phát triển không? Hoặc có nên cho tôi một số loại ký tự đại diện liên quan? Hay tôi cần đưa ra quyết định dựa trên sự đánh đổi? Nếu vậy, sự đánh đổi liên quan đến từng kiểu phiên bản cụ thể là gì?

Có rất nhiều mô tả cấp cao về tính năng này trôi nổi ngoài kia - nhưng không rõ các bước thực tế mà một nhà phát triển làm việc nên thực hiện ở đây là gì, và / hoặc hậu quả thực sự của những bước đó là gì.

Tôi có cần phải xem thủ công mô-đun của mình mỗi khi tôi sử dụng một đoạn mã Magento lõi và thêm một dòng yêu cầu: ... vào composer.json không?

Có, mỗi khi trong mã của bạn, bạn sử dụng bất cứ thứ gì từ một mô-đun cốt lõi, bạn cần thêm nó vào yêu cầu của nhà soạn nhạc. Như bạn có thể muốn thứ tự tải của bạn nằm sau mô-đun lõi, tôi cũng đề nghị thêm nó vào module.xmltệp của bạn trong phần trình tự.

Hoặc có một công cụ tự động có thể làm điều đó cho tôi?

Tôi chưa đi qua bất kỳ. Nếu có xin vui lòng cho tôi biết. Nó sẽ cần phải là một công cụ khá tinh vi và có thể sẽ yêu cầu phạm vi kiểm tra đáng kể và sau đó chạy một ma trận gồm các phiên bản khác nhau để tạo ra một bộ làm việc.

Làm cách nào để chỉ định một phiên bản để đưa vào composer.json của tôi? Nó có nên là phiên bản mô-đun cụ thể mà tôi đã phát triển không? Hoặc có nên cho tôi một số loại ký tự đại diện liên quan? Hay tôi cần đưa ra quyết định dựa trên sự đánh đổi? Nếu vậy, sự đánh đổi liên quan đến từng kiểu phiên bản cụ thể là gì?

Tùy chọn để xác định số phiên bản

1. 100.0.2
   Chỉ hoạt động khi phiên bản cụ thể này

2. 100.0.*
*là một ký tự đại diện và có thể được thay thế bằng bất kỳ số phiên bản 100.0.0, 100.0.1, ...,100.0.120

3. ~100.0.2
   Làm cho 2 ký tự đại diện mà chỉ có thể đi lên vì vậy 100.0.2, 100.0.3, ...,100.0.120

4. ^100.0.2
   Cho phép bất kỳ phát hành lên đến 101 nên 100.0.2, 100.0.3, ..., 100.1.0,100.2.5

Đối với tùy chọn 2-4 nếu cài đặt ổn định của bạn cho phép, nó cũng sẽ bao gồm các phiên bản như 100.0.1-beta

Công dụng thực tế

Tùy chọn 1.) là lựa chọn thận trọng nhất, bạn biết phiên bản nào bạn đã phát triển và chỉ chấp nhận làm việc với phiên bản cụ thể này - mô-đun của bạn chỉ có thể được cài đặt cùng với mô-đun cụ thể đó tại phiên bản đó. Tất cả các nỗ lực cài đặt / nâng cấp khác sẽ thất bại với thông báo của nhà soạn nhạc nhấn mạnh rằng nó không thể tìm thấy một bộ thành phần có thể cài đặt được.

Tùy chọn 2.) Tôi nghĩ có thể được coi là không tùy chọn như được bao phủ bởi Tùy chọn 3.) nếu bạn sử dụng nó như ~100.0.0

Tùy chọn 3.) Tương thích miễn là không có tính năng mới nào được giới thiệu

Tùy chọn 4.) Tương thích miễn là không có thay đổi vi phạm nào được đưa ra

Đánh đổi

1 Tiện ích mở rộng của bạn chỉ hoạt động cho 1 phiên bản mô-đun Magento (về mặt kỹ thuật nếu không có bất kỳ thay đổi nào trong mô-đun, số phiên bản không nên tăng và nhiều phiên bản Magento Project về mặt lý thuyết có thể bao gồm cùng mô-đun lõi Magento với cùng một phiên bản. chưa thấy điều này và có vẻ như nó yêu cầu một số thay đổi quá trình ở phần cuối Magento xem tại đây). Vì bạn rất gắn bó với 1 phiên bản mô-đun lõi Magento, bạn kết thúc với rất nhiều phiên bản và phiên bản tiện ích mở rộng của riêng bạn, nếu bạn muốn duy trì khả năng tương thích.

3-4 Tiện ích mở rộng của bạn hoạt động với nhiều phiên bản Magento và bạn không cần phải phát hành các phiên bản tiện ích mở rộng khác nhau mỗi khi Magento phát hành phiên bản mới. Nhược điểm ở đây là bạn yêu cầu khả năng tương thích mặc dù một thay đổi có thể được đưa ra trong Magento không tương thích với mã của riêng bạn. Rủi ro này là có thật vì định nghĩa của Magento về phiên bản ngữ nghĩa cho các bản phát hành mô-đun của riêng họ chỉ mở rộng đến những gì được đánh dấu bằng @apichú thích (thêm về vấn đề này trong vấn đề GitHub này ) với phạm vi hạn chế.

tl; dr;
100.0.2Chơi nó an toàn, rất nhiều bản phát hành để duy trì cho bạn
^100.0.2Phiên bản ngữ nghĩa hoạt động như thế nào, ít bản phát hành hơn cho bạn nhưng có rủi ro cao hơn do phạm vi giới hạn của @apicác lớp và phương thức chú thích. Nếu bạn có một phần mở rộng 100% sử dụng các lớp và phương thức bị xử phạt thì đây sẽ là lựa chọn rõ ràng.

Nó có thể giống như 0.1.0-alpha1 -> 0.1.0-alpha2, 0.1.0-alpha3,dựa trên sự ổn định của mô-đun. Như được chia sẻ trong tài liệu, yêu cầu sẽ diễn ra như sau: -

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

Dựa trên cập nhật của bạn, điều này cần được cập nhật như: -

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

Tôi không nghĩ có bất kỳ hệ thống tự động nào cho việc này, nhưng theo tài liệu, điều rất quan trọng là phải tuân theo điều này.

Nhưng bạn nên sử dụng PATCH nếu có sửa lỗi nhỏ trong mô-đun của mình.

Tham khảo

PATCH chỉ ra các sửa lỗi tương thích ngược

Bạn đúng câu trả lời là không rõ ràng, nhưng bạn có thể thấy nó đã được cập nhật cách đây khoảng 1 năm. Nhưng đây là cách nó được.