2010-09-16 34 views
70

Tôi thường bắt đầu dự án của mình với phiên bản 1.0.0. Ngay sau khi tôi có một số công cụ với nhau, tôi phát hành nó là 1.0.0 và tiếp tục với 1.1.0.Sử dụng làm phiên bản ban đầu là gì?

Tuy nhiên, điều này dẫn đến có thể sử dụng được nhưng không chính xác tính năng phiên bản hoàn chỉnh 1.0.0 của hầu hết nội dung tôi viết. Sau đó tôi thêm các tính năng và nhận được một phiên bản phong nha ở đâu đó khoảng 1.6.0. Nhiều dự án bắt đầu với phiên bản 0.1.0, có thể sử dụng được với phiên bản 1.0.0 của tôi.

Bạn sẽ làm gì? Bắt đầu với phiên bản 1.0.0 hoặc 0.1.0?

Số cuối cùng chỉ dành cho bản phát hành bản vá lỗi. Bạn có thể nghĩ rằng 1.0.0 của tôi là 1.0 và 0.1.0 là 0.1 là dễ dàng hơn cho bạn.

+1

Tôi vừa phát hiện ra "phiên bản ngữ nghĩa" (http://semver.org/), đó là điều tôi muốn làm. Tuy nhiên, tôi không tạo API và nó đang nói về API, vì vậy lời khuyên 1.0.0 không thực sự áp dụng. – Noarth

+0

Tương tự như: http://stackoverflow.com/questions/1795920/how-do-other-development-teams-approach-version-numbers/1795940#1795940 –

+0

bản sao có thể có của [Phiên bản đầu tiên phải là phiên bản 0.1 hoặc 1.0 b?] (http://stackoverflow.com/questions/7139/should-a-first-release-be-an-0-1-version-or-1-0b) –

Trả lời

-8

Phiên bản của tôi được thúc đẩy bởi quá trình thiết lập. Tôi muốn nó thay thế các phiên bản cũ hơn, vì vậy tôi tiếp tục tăng nó trong các bước nhảy có ý nghĩa với tôi.

Đôi khi, phiên bản được điều khiển bởi khách hàng, đặc biệt nếu bạn đang phát hành mã cho công chúng.

Nếu đó là cuộc gọi của bạn, hãy làm bất cứ điều gì phù hợp nhất với bạn. Tôi đã có một số vấn đề với các phiên bản trước 1.0 vì vậy tôi bắt đầu với điều đó.

+1

Tôi nghĩ sẽ thực hiện theo cách tương tự, như sau: Bắt đầu với 1.0.0 cho các ứng dụng và với 0.1.0 cho các thư viện. Tôi nghĩ rằng 0.1.0 có vẻ giống như một bản phát hành trước cho một ứng dụng, và tôi nghĩ nó vô lý trong bao lâu, các dự án mã nguồn mở được sử dụng rộng rãi là dưới 1.0 trong nhiều năm. Tôi có thể làm điều đó một cách khác khi làm việc với những người khác: Tôi sẽ có một số loại kế hoạch tính năng và hiển thị một số tiền phát hành cho đồng nghiệp của tôi, vì vậy bắt đầu với 0,1 sẽ có ý nghĩa. Nhưng bản phát hành công khai sẽ là> = 1.0.0. – Noarth

-4

bắt đầu bằng 0.0.0 và di chuyển từ đó.

+3

Điều đó có nghĩa là bạn sẽ thực sự làm một 0.0 .0 phát hành? Tôi bắt đầu với số đầu tiên mà tôi sẽ phát hành. – Noarth

1

Khi tôi nhận được phiên bản hoàn chỉnh có thể sử dụng nhưng không có tính năng đầu tiên, tôi thường cố gắng đánh giá khoảng cách đến phiên bản đầy đủ tính năng, ví dụ như lần đầu tiên sử dụng được 33% tính năng 0.3.0 hoặc tương tự. Sau đó, khi tôi di chuyển theo hướng tính năng hoàn thành các phiên bản tương ứng có được số cho một cách tương tự.

Nhưng khi bạn chuyển sang phiên bản hoàn chỉnh, tính năng trước đây cần phải thay đổi

+3

Điều đó ngụ ý rằng bạn chỉ có thể đi xa tới 0.9.0, nhưng tôi biết rất nhiều dự án tiếp tục như 0.25.0. – Noarth

+0

Tôi có xu hướng sử dụng tập hợp chữ số cuối cùng để thay đổi nhỏ cũng như sửa lỗi và giữ tập hợp chữ số giữa cho các thay đổi khá lớn vì vậy không bao giờ thực sự cần phải nhập hai chữ số cho số giữa – Tristan

-9

Bắt đầu với 1.1.1 và tiếp tục từ đó.

1

Tôi nghĩ các yếu tố khác nhau sẽ được phát huy tại đây. Tác động tâm lý/tiếp thị của số phiên bản (số phiên bản tăng thường => hơn $$$, mọi người không muốn mua phiên bản beta 0.99, v.v.) phải được tính đến. Số phiên bản "Logic" có thể hữu ích khi làm việc trong một nhóm lớn.

Và tôi thích cách linux có số lẻ cho các phiên bản không ổn định và thậm chí là số cho phiên bản ổn định.

0

Số phiên bản hoàn toàn tùy thuộc vào bạn. Hãy làm những gì có ý nghĩa với bạn và nhất quán. Không ai nói bạn phải bắt đầu từ 0 hoặc 0.0 hoặc 1.0 hoặc 1.1.

Các lập trình viên tuyệt vời đã thực sự sử dụng hệ thống đánh số phiên bản làm trò đùa địa phương. Ví dụ (Wikipedia):

Kể từ phiên bản 3, TeX đã sử dụng một phiên bản mang phong cách riêng đánh số hệ thống, nơi cập nhật đã được chỉ bằng cách thêm một chữ số thêm tại cuối thập phân, do đó phiên bản số asymptotically phương pháp tiếp cận π. Đây là một sự phản ánh của thực tế là TeX hiện rất ổn định, và chỉ những cập nhật nhỏ là được mong đợi. Phiên bản hiện tại của TeX là 3.1415926; nó đã được cập nhật cuối tháng 3 năm 2008

Đối METAFONT:

METAFONT có một hệ thống versioning tương tự như TeX, nơi số tiệm tiếp cận e với mỗi phiên bản.

Cuối cùng, không phải là một số phiên bản, nhưng thú vị không kém là đề xuất công khai ban đầu của Google (IPO) đã được gửi với SEC để tăng $ 2.718,281,828 (thông báo rằng e ~ 2.718 281 828).

Quan điểm của tôi là: không cảm thấy rằng bạn cần phải theo dõi đám đông. Hãy sáng tạo và nhất quán.

-1

Thông thường, phiên bản có ý nghĩa với lập trình viên. Việc tăng số lượng lớn có thể cho thấy những thay đổi lớn ngăn chặn khả năng tương thích ngược. Các số khác trong số phiên bản có thể cho biết các tính năng hoặc sửa lỗi nhỏ hơn.

Nếu bạn lo lắng phiên bản 0.6.5 có vòng không đầy đủ, bạn có thể muốn tiếp thị nó theo phiên bản 1.0. Số phiên bản tiếp thị của bạn không cần khớp với số phiên bản nội bộ của bạn. Ví dụ, số phiên bản của Windows 7 là 6.1.

Sở thích cá nhân của tôi là bắt đầu từ 0.1.0 và chuyển từ đó.

-1

Phụ thuộc vào dự án. Đối với các công cụ dòng lệnh đơn giản, tôi thường bắt đầu khoảng 0.9 [.0] vì tôi chỉ xem xét việc phát hành hoặc đóng gói chúng khi chúng gần hoàn thành (hoặc sẵn sàng cho thử nghiệm beta). Các dự án phức tạp hơn bắt đầu khoảng 0.1 [.0] và một số thậm chí không bao giờ thấy 1.0. Tôi xem xét 1.0 phiên bản phát hành (hoặc ít nhất là một thử nghiệm beta hoặc bản phát hành được thử nghiệm cục bộ) và lập kế hoạch cho phù hợp.

Với các dự án nhóm, bất kỳ ai đặt thẻ phiên bản đầu tiên sẽ được quyết định :).

-2

Số phiên bản phải có ý nghĩa đối với bạn là Arrieta đã nhận xét chính xác trước đây.

Có thể theo sau một cái gì đó như: First # là thị trưởng phát hành, thứ hai là cùng một thị trưởng phát hành với một số tính năng được thêm vào và Third # là cùng một thị trưởng phát hành, với các tính năng tương tự nhưng với lỗi cố định hoặc thêm ít (nhưng đủ quan trọng) thay đổi.

1.3.2 => Bản phát hành đầu tiên, với nhiều tính năng hơn và một số lỗi được sửa.

Tuy nhiên, đối với người dùng cuối cùng, một số được sử dụng với số lượng lớn cho các bản phát hành cuối cùng.

Ví dụ: Corel 8, cho 8.0.0, 8.0.1, 8.2.2, v.v. Corel 9, cho 9.0.0 ... v.v.

Và chủ yếu là nhiều hơn về chiến lược tiếp thị như: Corel X5 thay vì Corel 15.0.2 chẳng hạn.

Tôi sẽ nói rằng điều đó tùy thuộc vào số phiên bản dành cho bạn hay cho khách hàng.

103

Tiêu chuẩn Semantic Versioning 2.0.0 nói:

Điều đơn giản nhất để làm là bắt đầu phát hành phát triển ban đầu của bạn tại 0.1.0 và sau đó tăng phiên bản nhỏ cho mỗi bản phát hành tiếp theo.

Bạn có thể chuyển từ 0.3.0 thẳng sang 1.0.0. Nó cũng hoàn toàn ổn khi được ở 0.23.0. Bắt đầu từ 0,4.0 là hơi khó dự đoán vì nó cho thấy đã có các phiên bản được xuất bản trước đó.

Ngoài ra, lưu ý rằng 0.y.z được giữ sang một bên để lặp lại nhanh chóng, do đó phát triển ban đầu (và do đó rất nhiều thay đổi phá vỡ) không để bạn ở một cái gì đó ngớ ngẩn như 142.6.0. Thay vì chạm vào phiên bản chính, hãy vuốt phiên bản phụ vào mỗi thay đổi đột phá cho đến khi bạn phát hành 1.0.0:

Phiên bản chính zero (0.y.z) là để phát triển ban đầu. Bất cứ điều gì cũng có thể thay đổi bất cứ lúc nào. API công cộng không được coi là ổn định.

0

Khi chọn số phiên bản cho gói npm, hãy lưu ý rằng semver ranges sẽ không hoạt động dưới v1.0.0. Đó là,

"dependencies": { 
    "my-package": "^0.5" 
} 

tương đương với

"dependencies": { 
    "my-package": "0.5" 
} 

Nếu bạn muốn để có thể sử dụng semver phạm vi, hoặc bạn muốn cho người khác sử dụng chúng, bạn có thể muốn bắt đầu với 1.0.0

Các vấn đề liên quan