Hãy quên đi những gì Perl Best Practices nói. Nó không phải là kinh thánh, và nó chỉ đơn thuần gợi ý sử dụng từ khóa RCS bởi vì tại thời điểm nó được viết không ai nghĩ về các hệ thống kiểm soát nguồn khác. Mục tiêu của bạn sẽ không bao giờ tuân thủ việc triển khai cụ thể của PBP, nhưng hãy điều chỉnh ý tưởng trong PBP về tình hình của riêng bạn. Hãy nhớ đọc chương đầu tiên của cuốn sách đó.
Trước tiên, hãy sửa chữa những giả định của bạn:
Bạn không cần một phiên bản riêng biệt cho mỗi mô-đun trong một phân phối. Bạn chỉ cần cung cấp cho mỗi tệp mô-đun một phiên bản khác với phiên bản trước đó. Mỗi mô-đun trong bản phân phối có thể có cùng một phiên bản và khi chúng thực hiện, tất cả chúng có thể vẫn lớn hơn phiên bản từ bản phân phối cuối cùng.
Tại sao không thay đổi phiên bản của mô-đun thay đổi nhanh theo cách thủ công?Bạn nên xác định các điểm nơi mã của bạn trở thành thứ mà mọi người có thể sử dụng. Tại những điểm đó, bạn làm điều gì đó để nói rằng bạn đã đưa ra quyết định rằng sản phẩm công việc của bạn nên được phân phối, cho dù là bản thử nghiệm hay bản phát hành ổn định. Bạn thay đổi các phiên bản như một cách để nói cho mọi người biết về sự phát triển của bạn. Khi bạn để hệ thống kiểm soát nguồn làm điều đó chỉ vì bạn cam kết, bạn sẽ mất cơ hội biểu thị các chu kỳ trong sự phát triển của mình. Ví dụ, tôi thường sử dụng hai bản phát hành vị trí nhỏ. Điều đó có nghĩa là tôi nhận được 100 bản phát hành trước khi cuộc đối đầu hết hạn và tôi cần phải nhấn mạnh phiên bản chính để khôi phục thứ tự sắp xếp hợp lý. Đó là không đủ không gian phiên bản nếu tôi để VCS xử lý việc này cho tôi.
Tôi đã từng sử dụng từ khóa RCS để liên kết các phiên bản của mô-đun với số đăng ký hoặc sửa đổi của họ, nhưng tôi chưa bao giờ thực sự thích điều đó. Tôi thực hiện nhiều cam kết cho một tập tin trước khi nó đã sẵn sàng để trở thành phiên bản tiếp theo, và tôi không cần $VERSION thay đổi chỉ vì tôi đã sửa lỗi đánh máy tài liệu. Sẽ có những bước nhảy lớn trong số phiên bản vì tôi đã thực hiện rất nhiều thay đổi nhỏ.
Bây giờ tôi chỉ thay đổi phiên bản của tất cả các tệp mô-đun của mình khi tôi sẵn sàng phát hành bản phân phối mới. Tôi sử dụng ppi_version thay đổi tất cả các phiên bản cùng một lúc:
ppi_version change 1.23 1.24
Tất cả các tập tin mô-đun của tôi nhận được cùng một $VERSION. Tôi không cần sử dụng $VERSION để phân biệt chúng vì tôi sử dụng các tính năng kiểm soát nguồn thông thường để thực hiện điều đó. Tôi không cần $VERSION để liên kết với cam kết cụ thể.
Nếu tôi đang làm việc hướng tới bản phân phối mới từ phiên bản 1.23, tôi bắt đầu tạo phiên bản phát triển 1.23_01, 1.23_02, v.v, nhưng chỉ khi tôi sẵn sàng để mọi người thử các phiên bản đó. Tôi thay đổi phiên bản ở đầu chu kỳ, chứ không phải kết thúc. Tất cả các cam kết của tôi dẫn đến bản phát hành tiếp theo đã có phiên bản tiếp theo của họ. Tôi cũng ghi chép về những gì tôi muốn chu kỳ đó hoàn thành.
Khi tôi nghĩ rằng đó là khởi đầu của một chu kỳ mới, tôi gặp lại phiên bản. Khi tôi nghĩ rằng tôi có bản phát hành ổn định, tôi thay đổi phát triển $VERSION thành bản ổn định, như 1.23_04 đến 1.24. Bất cứ khi nào tôi phát hành một cái gì đó, tôi cũng gắn thẻ trong điều khiển nguồn. Tôi có thể thấy các điểm phát triển chính của tôi ở đâu với sự kiểm soát nguồn khá dễ dàng.
Mọi thứ đều dễ dàng hơn theo cách này đối với tôi. Không có gì liên quan đến kiểm soát nguồn mà tôi quyết định sử dụng, vì vậy tôi không phải làm lại mọi thứ nếu tôi thay đổi những gì tôi sử dụng.
Đây là một câu hỏi hay. Nhưng làm Perl :: Critic và/hoặc PBP thực sự đề nghị số phiên bản RCS-backed? AFAI, họ thực sự không quan tâm đến những con số đó đến từ đâu. – innaM
@Manni: vâng, họ không quan tâm, nhưng vẫn khuyên RCS là "thực hành tốt nhất": "Thực tiễn phổ biến là sử dụng từ khóa $ Revision: 3629 $ để tự động xác định biến $ VERSION như sau: ($ VERSION) = '$ Sửa đổi: 3629 $' = ~ m {\ $ Bản sửa đổi: \ s + (\ S +)} x; " –
Tôi thông cảm vì tôi hiện đang ở trong tình trạng tương tự. Tôi đoán là với ngày càng nhiều dự án sử dụng git, thực hành sẽ trở nên ít phổ biến hơn. – innaM