Những gì để sử dụng như một phiên bản ban đầu? [đóng cửa]

Tôi thường bắt đầu các dự án của mình với phiên bản 1.0.0. Ngay sau khi tôi có một số thứ cùng nhau, tôi phát hành nó dưới dạng 1.0.0 và chuyển sang 1.1.0.

Tuy nhiên, điều này dẫn đến có thể sử dụng được nhưng không chính xác là phiên bản hoàn chỉnh 1.0.0 của hầu hết những thứ 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 tốt ở đâu đó xung quanh 1.6.0. Nhiều dự án bắt đầu với phiên bản 0.1.0, sẽ có thể sử dụng được như phiên bản 1.0.0 của tôi.

Bạn sẽ đề nghị làm gì? Bắt đầu với 1.0.0 hay 0.1.0?

Nhân tiện, số cuối cùng chỉ dành cho các bản phát hành sửa lỗi. Bạn có thể nghĩ 1.0.0 của tôi là 1.0 và 0.1.0 là 0.1 sẽ dễ dàng hơn cho bạn.

Phiên bản của tôi được thúc đẩy bởi 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ó theo những bước nhảy có ý nghĩa với tôi.

Tuy nhiên, đôi khi, việc lập phiên bản được thúc đẩy 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 đã gặp một số vấn đề với các phiên bản trước 1.0 nên tôi bắt đầu với điều đó.

Các Semantic Versioning 2.0.0 tiêu chuẩn nói:

Điều đơn giản nhất cần làm là bắt đầu bản phát triển ban đầu của bạn ở mức 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 thẳng từ 0.3.0 lên 1.0.0. Nó cũng hoàn toàn ổn khi ở mức 0.23.0. Bắt đầu từ 0.4.0 là hơi khó tin vì nó cho thấy đã có các phiên bản được xuất bản trước đó.

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

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

Số phiên bản hoàn toàn tùy thuộc vào bạn. Làm những gì có ý nghĩa với bạn và nhất quán. Không ai nói rằng 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 vĩ đại đã thực sự sử dụng hệ thống đánh số phiên bản như một trò đùa cục bộ. Ví dụ (Wikipedia):

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

Đối với METAFONT:

Metafont có một hệ thống lập phiên bản tương tự như của TeX, trong đó số tiệm cận e với mỗi lần sửa đổi.

Cuối cùng, không phải là một con số hoàn toàn, nhưng thú vị không kém, là đợt phát hành cổ phiếu lần đầu ra công chúng (IPO) của Google đã được đệ trình lên SEC để huy động được 2.718.281.828 đô la (lưu ý rằng e ~ 2.718 281 828).

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

Tôi nghĩ rằng các yếu tố khác nhau phát huy tác dụng ở đâ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 xuyên => nhiều $$$ 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ể giúp í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 phiên bản không ổn định và số chẵn cho phiên bản ổn định.

Khi tôi chuẩn bị sẵn sàng phiên bản có thể sử dụng đầu tiên nhưng không phải là phiên bản hoàn chỉnh về tính năng, tôi thường cố gắng đánh giá xem nó tiến tới phiên bản hoàn chỉnh về tính năng bao xa, vì vậy, ví dụ: nếu tính năng có thể sử dụng đầu tiên của tôi đã hoàn thành 33%, tôi đặt phiên bản là số 0.3.0 hoặc giống. Sau đó, khi tôi chuyển sang các phiên bản tương ứng có tính năng hoàn chỉnh sẽ nhận được những con số theo cách tương tự.

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

Khi chọn số phiên bản cho một npmgói, hãy lưu ý rằng đối với các phụ thuộc được liệt kê trong package.json phạm vi semver sẽ không hoạt động bên 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 phạm vi semver hoặc bạn muốn cho phép người khác sử dụng chúng, bạn có thể muốn bắt đầu với 1.0.0

Thông thường, việc lập phiên bản có một số ý nghĩa đối 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 cả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 nhỏ hơn hoặc các bản sửa lỗi.

Nếu bạn lo lắng rằng phiên bản 0.6.5 chưa hoàn thiện, bạn có thể muốn tiếp thị nó dưới 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à bắt đầu từ đó.

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ỉ cân nhắc 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ờ nhìn thấy 1.0. Tôi coi 1.0 là một phiên bản phát hành (hoặc ít nhất là một phiên bản beta hoặc bản phát hành thử nghiệm cục bộ) và lập kế hoạch cho phù hợp.

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

0.1.0 là những gì tôi bắt đầu và đi lên từ đó. Đây là những gì tôi đã điều chỉnh cho Xploration By Adrian, mặc dù trong những năm đầu tôi sử dụng rất rời rạc và sử dụng 1.0.0, 0.0.1, và một số phiên bản khác. Nhưng tôi khuyên bạn nên bắt đầu từ 0.1.0 và bắt đầu từ đó.

Theo Semver, hãy đặt trước a và c trong abc cho A. Bạn phát hành chính thức đầu tiên và C. Các bản sửa lỗi và bản vá. Điều này là do một phiên bản chính thường phá vỡ mã cũ hơn. Và các bản vá chỉ đơn giản là sửa lỗi. Đây là tất cả sở thích cá nhân, 0.99.0 không có nghĩa là bạn phải chuyển sang 1.0.0, v.v. Tôi đã thấy một số chuyển đến 0.218.42.

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

Có thể theo sau một cái gì đó như: # Đầu tiên là bản phát hành thị trưởng, Thứ hai # là cùng một bản phát hành thị trưởng với một số tính năng được thêm vào và Thứ ba # là cùng một bản phát hành thị trưởng, với các tính năng tương tự nhưng có các lỗi đã sửa hoặc được bổ sung một số thay đổi nhỏ (nhưng đủ quan trọng).

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ố đã quen 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à về các 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 đó phụ thuộc vào số phiên bản dành cho bạn hay cho khách hàng.

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

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