Ngã ba một dự án, số phiên bản của tôi bắt đầu từ đâu?


12

Tôi đã rẽ nhánh một dự án và đã thay đổi rất nhiều dự án. Cái ngã ba này không chỉ là một thay đổi tính năng nhỏ ở đây và một bản sửa lỗi bị chôn vùi ở đó, đó là một thay đổi khá lớn. Chỉ hầu hết các mã cốt lõi được chia sẻ.

Tôi đã rẽ nhánh dự án này tại v2.5.0. Trong một thời gian, tôi đã bắt đầu phiên bản ngã ba của mình tại v3.0. Tuy nhiên tôi không chắc liệu đây có phải là cách đúng đắn hay không, chủ yếu là vì khi dự án đó đạt phiên bản 3.0, mọi thứ trở nên khó hiểu. Nhưng tôi không muốn bắt đầu lại ở v1.0 hoặc v0.1 bởi vì điều đó hàm ý sự non trẻ, không ổn định và không bắt buộc của một dự án. Điều này không đúng, vì hầu hết các mã cốt lõi đều rất tinh tế và ổn định.

Tôi thực sự không biết phải làm gì, vì vậy tôi hỏi ở đây: Cách tiêu chuẩn để đối phó với tình huống này là gì? Làm hầu hết các dĩa bắt đầu lại, tăng số phiên bản hoặc làm một cái gì đó khác mà tôi không biết.


5
Tôi không thấy 1.0 imlies infancy hay bất ổn. Bất cứ điều gì dưới 1.0 có, nhưng 1.0 ngụ ý rằng nó đã hết thời kỳ 'sơ khai' và sẵn sàng khuấy động. Nếu điều đó làm bạn thoải mái hơn, hãy đi với 1.1 (10% trưởng thành thêm !!!);)
Mchl

1
Vì tò mò, bạn đã làm gì?
compman

Câu trả lời:


13

Hầu hết các dĩa mà tôi đã thấy bắt đầu lại từ phiên bản 1.0. Nhưng tôi cho rằng bạn cũng đã thay đổi tên của ngã ba của mình, vì vậy tôi không chắc tại sao sẽ có sự nhầm lẫn nếu bạn chỉ đơn giản bắt đầu từ phiên bản 3.0.

Những gì tôi sẽ làm là thay đổi tên của dự án, phát hành phiên bản 1.0 và làm rõ rằng dự án là một nhánh của dự án khác. Tôi không nghĩ sẽ có bất kỳ sự nhầm lẫn nào với cách tiếp cận đó.

Nếu bạn thực sự lo lắng về nhãn "1.0", chỉ cần phát hành phiên bản 2.0 một thời gian ngắn sau 1.0 ...


... hoặc phát hành trực tiếp v2.0, bỏ qua v1.0 hoàn toàn. Đây không phải là lần đầu tiên nó được thực hiện.
Konamiman

Tại công ty của tôi, một dự án bắt đầu từ v2.4.
dùng253751

6

Có lộ trình của riêng bạn và tuân thủ nó, bắt đầu với số của phiên bản gốc nhưng đừng cố chạy đua với phiên bản hiện tại của sản phẩm gốc.


1
Nếu bạn không cố gắng song song dự án ban đầu theo một cách nào đó, thì sẽ không có mối tương quan có ý nghĩa giữa các số phiên bản trong tương lai. Điều đó có nghĩa là không có điểm nào cố gắng thiết lập mối tương quan như vậy ngay bây giờ - bằng cách bắt đầu từ 3.0 - bởi vì nó sẽ chỉ thiết lập một kỳ vọng không thể thực hiện được.
Tom Anderson

Tôi đứng sửa. Bạn nên bắt đầu v1.0 của riêng bạn, điều đó sẽ giúp bạn phân biệt. Các phiên bản nên có ý nghĩa gì đó, không chỉ là một số pha nguy hiểm tiếp thị (v.gr. "v5.4" chỉ để không trông mới).
dukeofgaming

1
@TomAnderson: Nếu anh ta giả mạo, giả sử, phiên bản 2.5 và tạo phiên bản đầu tiên của ngã ba của mình là 2.6 hoặc 3.0, anh ta có thể chỉ ra ứng dụng khác là lịch sử đầy đủ của dự án của mình. Đó là một mối tương quan có ý nghĩa khiêm tốn.
DougM

3

Bạn có thể muốn xem xét nếu (và bao nhiêu) dự án của bạn sẽ liên quan đến dự án ban đầu. Nếu bạn có kế hoạch chuyển các tính năng mới từ dự án ban đầu vào dự án của mình, bạn có thể xem xét giữ số phiên bản của mình khớp với các phiên bản gốc.

Để làm ví dụ, hãy xem MariaDB, một nhánh của MySQL. Họ muốn giữ nó thay thế 'thả xuống' cho MySQL, vì vậy, ví dụ MariaDB 5.2 có tất cả các tính năng của MySQL 5.2.

Xem: http://kb.askmonty.org/v/mariadb-versus-mysql

Lưu ý: Vì câu trả lời này đã được đăng, MariaDB đã chuyển hướng đáng kể khỏi MySQL và hiện đang theo sơ đồ phiên bản riêng của nó.


1

0,1 có thể chỉ ra giai đoạn trứng nước, nhưng verion 1.0+ có nghĩa là ổn định. Sự gia tăng số lượng phiên bản chính, ví dụ 2.0, 3.0, thường cho thấy sự thay đổi tính năng lớn.

Ví dụ

  • Phiên bản 1.0 của ứng dụng của tôi là một công cụ để chạy các kịch bản thử nghiệm với thiết lập,
  • Phiên bản 2.0 đã loại bỏ sự khác biệt giữa tập lệnh thử nghiệm và tập lệnh thiết lập môi trường,
  • Phiên bản 3.0 đã thêm GUI để viết tập lệnh dưới dạng biểu đồ luồng. Chúng là những sản phẩm khác nhau rõ rệt, nhưng ngay cả Phiên bản 1 là một sản phẩm hoạt động, hoàn toàn ổn định, v.v. Phiên bản 2 và 3 xuất hiện vì quyết định những thay đổi lớn này sẽ tốt. Nếu chúng tôi không muốn những thay đổi lớn này và tiếp tục sửa lỗi, v.v. Số phiên bản nhỏ sẽ tăng lên, 1.10.1.20, v.v., và điều đó sẽ ổn.

Điều tôi đang nói là số phiên bản chính không biểu thị sự trưởng thành, chúng chỉ ra các bộ tính năng chính. Bây giờ đó là một chút tiếp tuyến từ cách đánh số phiên bản sản phẩm của bạn.

Những gì tôi đã thấy trước đây, điều mà tôi lặng lẽ thích là bắt đầu phiên bản lại từ 1.0 (hoặc từ 3.0 nếu bạn thực sự thích) và sau đó trong ngoặc đơn cho biết phiên bản gốc nào mà nó có tính năng mới nhất.

  • Ban đầu: " MyFork v1.1 (dựa trên OrigProg v3.0)
  • Một số lỗi được tạo cho MyFork: MyFork v1.3 (dựa trên OrigProg v3.0)
  • OrigProg đã phát hành một phiên bản chính và MyFork đã kéo và sáp nhập: MyFork v2.1 (dựa trên OrigProg v4.0)
  • Đã thực hiện một số thay đổi lớn đối với MyFork (có thể sẽ không thể dễ dàng hợp nhất với OrigProg nữa): MyFork v3.0 (dựa trên OrigProg v4.0)

0

Nếu có thể, hợp nhất ngã ba của bạn trở lại dự án ban đầu. Tôi không thể nhấn mạnh đủ điều này.

Lấy lại số phiên bản của bạn, sau đó sử dụng số bạn đã chia từ cộng với hậu tố ngày.


2
Chuyển từ "Python 1.1" sang "Userthon 1.1. {DATE}" phá vỡ định dạng dự kiến ​​của các số verison.
DougM
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.