Merge pull request #461 from lamngockhuong/patch-1

lang/vi/index.md

@@ -22,7 +22,7 @@ Giới thiệu
 
 Trong thế giới của quản lý phần mềm, ở đó tồn tại một nơi đáng sợ, được gọi là "địa ngục phụ thuộc". Hệ thống của bạn ngày càng lớn hơn và bạn càng tích hợp nhiều gói vào trong phần mềm của mình hơn, đồng nghĩa với việc bạn càng lún sâu một cách tuyệt vọng vào địa ngục này.
 
-Trong các hệ thống phụ thuộc nhiều vào các yếu tố khác (gói, hệ thống,...), phát hành một phiên bản mới có thể nhanh chóng trở thành một cơn ác mộng. Nếu các thông số kỹ thuật phụ thuộc quá chặt chẽ với nhau, bạn có nguy cơ bị khóa phiên bản (không có khả năng nâng cấp một gói mà không phải phát hành các phiên bản mới của mỗi gói phụ thuộc). Nếu các yếu tố phục thuộc được chỉ định quá lỏng lẻo, chắc chắn bạn sẽ bị ảnh hưởng bởi tính hỗ tạp của phiên bản (giả định khả năng tương thích với nhiều phiên bản trong tương lai là hợp lý). Cả hai trường hợp này đều đưa bạn đến đích đến là địa ngục phụ thuộc, ngăn dự án của bạn tiếp tục phát triển.
+Trong các hệ thống phụ thuộc nhiều vào các yếu tố khác (gói, hệ thống,...), phát hành một phiên bản mới có thể nhanh chóng trở thành một cơn ác mộng. Nếu các thông số kỹ thuật phụ thuộc quá chặt chẽ với nhau, bạn có nguy cơ bị khóa phiên bản (không có khả năng nâng cấp một gói mà không phải phát hành các phiên bản mới của mỗi gói phụ thuộc). Nếu các yếu tố phụ thuộc được chỉ định quá lỏng lẻo, chắc chắn bạn sẽ bị ảnh hưởng bởi tính hỗn tạp của phiên bản (giả định khả năng tương thích với nhiều phiên bản trong tương lai là hợp lý). Cả hai trường hợp này đều đưa bạn đến đích đến là địa ngục phụ thuộc, ngăn dự án của bạn tiếp tục phát triển.
 
 Để giải quyết vấn đề này, chúng tôi đề xuất một bộ quy tắc và quy định để đánh phiên bản. Các quy tắc này không nhất thiết dựa trên các quy tắc đã phổ biến rộng rãi trong cả phần mềm nguồn đóng và nguồn mở. Để bộ quy tắc này hoạt động, đầu tiên bạn cần xác định một tập public API, bao gồm tài liệu mô tả hoặc chính mã nguồn của API. Điều quan trọng là API phải rõ ràng và chính xác. Một khi bạn đã xác định được tập public API, bạn thông báo các thay đổi của API bằng cách đánh các phiên bản tương ứng. Bạn hãy xem lại định dạng phiên bản ban đầu, X.Y.Z (Major.Minor.Patch). Đối với những bản vá lỗi không làm thay đổi API, chúng ta tăng phiên bản Patch (Vá lỗi); với các thay đổi liên quan API, có thể tương thích ngược với phiên bản trước, tăng phiên bản Minor (Phụ); còn lại, đối với các thay đổi API mà không thể tương thích ngược với phiên bản trước, tăng phiên bản Major (Chính).
 
@@ -55,13 +55,13 @@ Các từ khóa “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHAL
 
 11. Mức độ ưu tiên đề cập đến cách các phiên bản được so sánh với nhau.
 
-    1. Mức độ ưu tiên PHẢI được tính bằng cách phiên bản thành các mã định dang phiên bản Major, phiên bản Minor và phiên bản Patch, theo thứ tự đã nêu. (Build metadata không tính vào mức độ ưu tiên)
+    1. Mức độ ưu tiên PHẢI được tính bằng cách phiên bản thành các mã định dạng phiên bản Major, phiên bản Minor và phiên bản Patch, theo thứ tự đã nêu. (Build metadata không tính vào mức độ ưu tiên)
 
     2. Mức độ ưu tiên được xác định bởi sự khác biệt đầu tiên khi so sánh từng mã định danh từ trái qua phải: phiên bản Major -> phiên bản Minor -> phiên bản Patch.
 
        Ví dụ: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1.
 
-    3. Trong trường hợp phiên bản Major, Minor và {atcj} đều bằng nhau, phiên bản phát hành trước có mức độ ưu tiên thấp hơn.
+    3. Trong trường hợp phiên bản Major, Minor và Patch đều bằng nhau, phiên bản pre-release có mức độ ưu tiên thấp hơn.
 
        Ví dụ: 1.0.0-alpha < 1.0.0.
 
@@ -71,7 +71,7 @@ Các từ khóa “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHAL
 
         2. Các mã định danh bao gồm chữ cái hoặc dấu gạch ngang được so sánh theo thứ tự sắp xếp trong bảng ASCII.
 
-        3. Định dang dạng số luôn có mức độ mưu tiên thấp hơn định danh dạng chữ hoặc ký tự đặc biệt.
+        3. Định danh dạng số luôn có mức độ mưu tiên thấp hơn định danh dạng chữ hoặc ký tự đặc biệt.
 
         4. Một tập các phiên bản pre-release lớn hơn có mức độ ưu tiên cao hơn một tập khác nhỏ hơn, nếu tất cả các phiên bản trước đó bằng nhau.
 
@@ -149,7 +149,7 @@ Tại sao nên sử dụng Sematic Versioning?
 
 Đây không phải là một ý tưởng mới hay mang tính cách mạng. Trong thực tế, bạn có thể làm một cái gì đó gần tương tự rồi. Vấn đề là "gần" cũng có nghĩa nó chưa đủ tốt. Nếu không có tuân thủ một số loại đặc tả chính thức, số phiên bản về cơ bản là vô dụng để việc quản lý phụ thuộc. Bằng cách đặt tên và định nghĩa rõ ràng cho các ý tưởng trên, việc truyền đạt ý định của bạn tới người dùng phần mềm trở nên dễ dàng hơn. Một khi những ý định này đã rõ ràng, các đặc tả phụ thuộc linh hoạt (nhưng không nên quá linh hoạt) có thể được thực hiện.
 
-Một ví dụ đơn giản chứng minh làm thế nào Sematic Versioning có thể biến địa ngục phụ thuộc thành dĩ vãng. Hãy xem xét một thư viện có tên là "Firetruck". Nó yêu cầu một gói có tên "Ladder". Tại thời điểm Firetruck được tạo ra, Ladder đang ở phiên bản 3.1.0. Vì Firetruck sử dụng một số tính năng mới được giới thiệu lần đầu trong 3.1.0, bạn hoàn toàn có thể chỉ định một cách an toàn phụ thuộc lớn hơn hoặc bằng 3.1.0 và nhỏ hơn 4.0.0. Giờ đây,khi Ladder phiên bản 3.1.1 và 3.2.0 ra mắt, bạn có thể hệ thống quản lý gói để cập nhật lên các phiên bản này, và bạn biết rằng chúng sẽ tương thích với phần mềm phụ thuộc hiện có.
+Một ví dụ đơn giản chứng minh làm thế nào Sematic Versioning có thể biến địa ngục phụ thuộc thành dĩ vãng. Hãy xem xét một thư viện có tên là "Firetruck". Nó yêu cầu một gói có tên "Ladder". Tại thời điểm Firetruck được tạo ra, Ladder đang ở phiên bản 3.1.0. Vì Firetruck sử dụng một số tính năng mới được giới thiệu lần đầu trong 3.1.0, bạn hoàn toàn có thể chỉ định một cách an toàn phụ thuộc lớn hơn hoặc bằng 3.1.0 và nhỏ hơn 4.0.0. Giờ đây, khi Ladder phiên bản 3.1.1 và 3.2.0 ra mắt, bạn có thể cập nhật lên các phiên bản này, và bạn biết rằng chúng sẽ tương thích với phần mềm phụ thuộc hiện có.
 
 Tất nhiên, với tư cách là nhà phát triển có trách nhiệm, bạn sẽ muốn xác minh rằng bất kỳ nâng cấp gói đều hoạt động như mong đợi. Thế giới thực là một nơi lộn xộn; không có gì chúng ta không thể làm nhưng hãy cảnh giác. Những gì bạn có thể làm là hãy để Sematic Versioning cung cấp cho bạn cách phát hành và nâng cấp các gói hợp lý, mà không cần phải tung ra các phiên bản mới của các gói phụ thuộc, giúp bạn tiết kiệm thời gian và giảm thiểu rắc rối.
 
@@ -160,17 +160,17 @@ Câu hỏi thường gặp
 
 ### Tôi nên xử lý các bản sửa đổi trong giai đoạn phát triển ban đầu 0.y.z như thế nào?
 
-Điều đơn giản nhất cần làm là bắt đầu phát hành phiên bản sơ khai của bạn ở 0.1.0 và sau đó tăng phiên bản Minor cho mỗi phản phát hành tiếp theo.
+Điều đơn giản nhất cần làm là bắt đầu phát hành phiên bản sơ khai của bạn ở 0.1.0 và sau đó tăng phiên bản Minor cho mỗi lần phát hành tiếp theo.
 
 ### Làm cách nào để biết khi nào phát hành 1.0.0?
 
 Nếu phần mềm của bạn đang được sử dụng thực tế, nó có lẽ đã là 1.0.0. Nếu bạn có một API ổn định mà người dùng phụ thuộc vào, bạn phải là 1.0.0. Nếu bạn lo lắng rất nhiều về khả năng tương thích ngược, bạn có lẽ đã là 1.0.0.
 
-### Điều này không ngăn cản sự phát triển nhanh chóng và lặp lại nhanh chóng sao?
+### Điều này có cản trở sự phát triển nhanh và lặp đi lặp lại nhanh chóng không?
 
-Phiên bản Major zero hướng tới sự phát triển nhanh chóng. Nếu bạn thay đổi API mỗi ngày, bạn vẫn nên ở phiên bản 0.y.z hoặc trên một nhánh phát triển riêng làm việc trên phiên bản chính tiếp theo.
+Phiên bản chính số không (Major version zero) hoàn toàn phù hợp cho giai đoạn phát triển nhanh. Nếu bạn thay đổi API mỗi ngày, bạn nên vẫn ở phiên bản 0.y.z hoặc sử dụng một nhánh phát triển riêng để làm việc trên phiên bản chính tiếp theo.
 
-### Nếu ngay cả những thay đổi ngược không tương thích nhỏ nhất với public API cũng yêu cầu một phiên bản chính, thì chẳng phải tôi sẽ đến phiên bản 42.0.0 rất nhanh sao?
+### Nếu ngay cả những thay đổi nhỏ nhất không tương thích ngược với public API đều yêu cầu tăng phiên bản chính, thì chẳng phải tôi sẽ đạt đến phiên bản 42.0.0 rất nhanh sao?
 
 Đây là một câu hỏi về sự phát triển có trách nhiệm và tầm nhìn. Không nên đưa những thay đổi không tương thích vào dự án có quá nhiều phụ thuộc. Những thay đổi không tương thích không nên được đưa vào một cách dễ dàng cho phần mềm có nhiều mã phụ thuộc. Chi phí phải chịu để nâng cấp là đáng kể. Khi bạn phải xử lý các phiên bản chính để phát hành các thay đổi không tương thích có nghĩa là bạn đã suy nghĩ thấu đáo về tác động của các thay đổi và đánh giá tỉ lệ/lợi ích liên quan.
 
@@ -225,7 +225,7 @@ Về chúng tôi
 
 Đặc tả của Sematic Versioning được viết bởi [Tom Preston-Werner](http://tom.preston-werner.com/), người sáng lập của Gravatars và đồng sáng lập GitHub.
 
-Nếu bạn muốn để lại một phản hồi, vui lòng [mở một vấn đền trên GitHub](https://github.com/semver/semver/issues)
+Nếu bạn muốn để lại một phản hồi, vui lòng [mở một vấn đề trên GitHub](https://github.com/semver/semver/issues)
 
 Giấy phép
 ---------