Làm thế nào để làm số phiên bản?

Công ty tôi đang xây dựng một sản phẩm. Nó sẽ được SVN phiên bản. Đó là một ứng dụng web nên về cơ bản sẽ không bao giờ có phiên bản không có một số tính năng trong đó và do đó luôn có thể được gắn nhãn là beta. Nhưng vì nó sẽ là một sản phẩm của công ty, tôi thực sự không muốn "cảnh giác không ổn định" ở đó. Vì vậy, làm thế nào bạn sẽ đi về phiên bản? 1.0 có ổn định không? Ngày xây dựng nên có trong số phiên bản? Nói cho tôi biết các bạn đang nghĩ gì!

[ chính ]. [ nhỏ ]. [ phát hành ]. [ xây dựng ]

chính : Thực sự là một quyết định tiếp thị. Bạn đã sẵn sàng gọi phiên bản 1.0 chưa? Công ty có coi đây là phiên bản chính mà khách hàng có thể phải trả nhiều tiền hơn không, hay đây là bản cập nhật của phiên bản chính hiện tại có thể miễn phí? Ít hơn một quyết định R & D và nhiều hơn một quyết định sản phẩm.

nhỏ : Bắt đầu từ 0 bất cứ khi nào chính tăng. +1 cho mọi phiên bản được công khai.

phát hành : Mỗi khi bạn đạt được một mốc phát triển và phát hành sản phẩm, thậm chí là nội bộ (ví dụ: QA), hãy tăng mức này. Điều này đặc biệt quan trọng để liên lạc giữa các đội trong tổ chức. Không cần phải nói, không bao giờ phát hành cùng một 'phát hành' hai lần (ngay cả trong nội bộ). Đặt lại về 0 khi nhỏ ++ hoặc chính ++.

build : Có thể là bản sửa đổi SVN, tôi thấy nó hoạt động tốt nhất.

Ví dụ
Chrome hiện tại của tôi: 83.0.4103.61

xyzg

gia số trong g không ổn định. (hoặc RC) gia tăng trong z là ổn định và có nghĩa là sửa lỗi.
gia số trong y là ổn định và có nghĩa là các tính năng mới.
gia số trong x là ổn định, phát hành chính mà không tương thích ngược 100%.

Tôi đã từng viết một "hướng dẫn phong cách phiên bản" công phu cho một dự án lớn của tôi. Dự án không thành hiện thực, nhưng hướng dẫn phong cách vẫn có sẵn trực tuyến . Đó là ý kiến ​​cá nhân của tôi, có lẽ nó hữu ích (hoặc truyền cảm hứng) cho bạn.

Coi chừng, đó là một văn bản dài và đi vào phiên bản thành phần so với phiên bản sản phẩm và những thứ tương tự. Nó cũng thể hiện ý kiến ​​mạnh mẽ về một số chương trình phiên bản phổ biến trong cộng đồng OSS, nhưng tôi có chúng, vì vậy tôi bày tỏ chúng. ;-)

Tôi không đồng ý với việc sử dụng số sửa đổi Subversion chẳng hạn. Bạn có thể muốn duy trì một phiên bản đã phát hành trong khi tiếp tục phát triển trong TRUNK, vì vậy bạn sẽ thiết lập một nhánh bảo trì - và phiên bản số sửa đổi của bạn sẽ bị giảm.

Chỉnh sửa: Tóm lại, nó phân biệt giữa các phiên bản tệp nguồn, các thành phần và sản phẩm tổng thể. Nó sử dụng một hệ thống phân tách xy versoning cho các thành phần và sản phẩm, với sự phụ thuộc lẫn nhau giữa hai yếu tố này giúp truy tìm phiên bản thành phần nào thuộc phiên bản sản phẩm nào tầm thường. Nó cũng nói về cách xử lý các chu kỳ alpha / beta / phát hành / vá mà không phá vỡ hệ thống. Trên thực tế, đó là một modus operandi cho toàn bộ chu trình phát triển, vì vậy bạn có thể muốn chọn cherry. ;-)

Chỉnh sửa 2: Khi đủ người thấy bài viết của tôi hữu ích để biến bài này thành "Câu trả lời hay", tôi bắt đầu làm lại bài báo. Phiên bản PDF và LaTeX hiện đã có sẵn, một bản viết lại hoàn chỉnh bao gồm ngôn ngữ tốt hơn và đồ họa giải thích sẽ xuất hiện ngay khi tôi có thể tìm thấy thời gian. Cảm ơn bạn đã bình chọn!

Lấy cho mình một chút cảm hứng từ Wikipedia: "Phiên bản phần mềm"

Một tùy chọn "mới" và "tương đối phổ biến" khác là Phiên bản ngữ nghĩa

Tóm lược:

Cho số phiên bản MAJOR.MINOR.PATCH, tăng:

1. Phiên bản CHÍNH khi bạn thực hiện các thay đổi API không tương thích,
2. Phiên bản MINOR khi bạn thêm chức năng theo cách tương thích ngược và
3. Phiên bản PATCH khi bạn thực hiện sửa lỗi tương thích ngược.

Các nhãn bổ sung cho siêu dữ liệu trước khi phát hành và xây dựng có sẵn dưới dạng các phần mở rộng cho định dạng MAJOR.MINOR.PATCH.

A B C D

Gia tăng: khi
- d : sửa lỗi
- c : bảo trì, ví dụ: cải thiện hiệu suất
- b : các tính năng mới
- a : thay đổi kiến ​​trúc

Bắt buộc là phần còn lại nhiều nhất, ví dụ: nếu có một tính năng mới và một lỗi đã được sửa thì bạn chỉ phải tăng b .

Dựa trên kinh nghiệm của tôi với quản lý phụ thuộc cấp độ nền tảng doanh nghiệp phức tạp và phiên bản phát hành, tôi đã đến để đề xuất một cách tiếp cận tôi muốn gọi Phiên bản bán ngữ nghĩa .

Về cơ bản, nó được xây dựng từ Semantic Versioning 2.0 nhưng không hoàn toàn nghiêm ngặt.

Phân đoạn phiên bản bán ngữ nghĩa:

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

Định dạng phân đoạn phát hành chính:

MARKETTING.MAJOR.MINOR.PATCH

Mỗi phân đoạn nên cho phép chữ và số, nhưng số học thuần túy được khuyến nghị cho các thay đổi tăng dần hợp lý.

Giống như SemVer, tôi đề xuất các thành phần Major, Minor và Patch để thể hiện các tầng tương thích ngược, nhưng tôi cũng khuyên bạn nên chuẩn bị trước một thành phần Marketing . Điều này cho phép chủ sở hữu sản phẩm, tính năng sử thi / nhóm và mối quan tâm kinh doanh để vượt qua thành phần chính độc lập với mối quan tâm tương thích kỹ thuật.

Không giống như các câu trả lời khác, tôi không khuyên bạn nên thêm số Build vào phân khúc chính. Thay vào đó, hãy thêm Phân đoạn sau phát hành theo '+' (ví dụ: 1.1.0.0 + build.42). SemVer gọi siêu dữ liệu xây dựng này, nhưng tôi nghĩ Phân đoạn sau phát hành rõ ràng hơn. Phân đoạn này rất tốt để khai báo dữ liệu hậu tố là không liên quan đến thông tin tương thích trong Phân đoạn phát hành chính . Các bản dựng tích hợp liên tục của bạn sau đó có thể được cung cấp số bản phát hành trước đó được gắn thêm số bản dựng tăng dần đặt lại sau mỗi bản phát hành chính (ví dụ: 1.1.0.0 -> 1.1.0.0 + build.1 -> 1.1.0.0 + build.2 -> 1.1.0.1). Một số người thay thế thích đặt số sửa đổi svn ở đây hoặc git commit sha để dễ dàng liên kết với kho lưu trữ mã. Một tùy chọn khác là sử dụng phân đoạn hậu phát hành cho các hotfix và các bản vá, tho có thể đáng để xem xét thêm một thành phần phát hành chính mới cho điều đó. Nó luôn có thể bị rơi khi tăng thành phần bản vá, vì các phiên bản được căn chỉnh và sắp xếp một cách hiệu quả.

Ngoài các phân đoạn phát hành và sau phát hành, mọi người thường muốn sử dụng Phân đoạn tiền phát hành để chỉ ra các bản phát hành trước gần như ổn định như bảng chữ cái, betas và các ứng cử viên phát hành. Cách tiếp cận SemVer cho điều này hoạt động tốt, nhưng tôi khuyên bạn nên tách các thành phần số khỏi các phân loại số alpha (ví dụ: 1.2.0.0 + alpha.2 hoặc 1.2.0.0 + RC.2). Thông thường, bạn sẽ tăng phân khúc phát hành cùng lúc với việc thêm phân đoạn sau phát hành và sau đó thả phân đoạn phát hành trước khi bạn tiếp tục phân khúc phát hành chính của chúng (ví dụ: 1.0.1.2 -> 1.2.0.0-RC.1 - > 1.2.0.0). Các phân đoạn tiền phát hành được thêm vào để chỉ ra rằng phiên bản phát hành sắp ra mắt, thường chỉ là một bộ tính năng cố định để thử nghiệm và chia sẻ sâu hơn mà không thay đổi từng phút dựa trên nhiều cam kết hơn.

Vẻ đẹp của việc có tất cả các định nghĩa ngữ nghĩa này theo cách bao trùm hầu hết các trường hợp sử dụng là bạn có thể phân tích, sắp xếp, so sánh và tăng chúng theo cách tiêu chuẩn. Điều này đặc biệt quan trọng khi sử dụng các hệ thống CI cho các ứng dụng phức tạp với nhiều thành phần nhỏ được phiên bản độc lập (như các dịch vụ vi mô), mỗi hệ thống có phụ thuộc được quản lý riêng.

Nếu bạn quan tâm, tôi đã viết một trình phân tích cú pháp bán ngữ nghĩa bằng ruby . Tôi không chỉ cần sử dụng mẫu này mà còn có thể quản lý các ứng dụng khác đã sử dụng nó.

"Số phiên bản" là một vấn đề đối với hệ thống kiểm soát phiên bản nội bộ của bạn. Số phát hành là một vấn đề khác nhau (và nên là KEPT khác nhau).

Bám sát một hệ thống phát hành MAJOR.MINOR đơn giản (như v1.27), trong đó MAJOR là mức độ tương thích (phiên bản 2.x không tương thích với hoặc ít nhất là khác biệt lớn so với phiên bản 1.x) và MINOR là bản phát hành lỗi hoặc cải tiến nhỏ của bạn . Miễn là bạn tuân theo định dạng XY, bạn cũng có thể sử dụng các hệ thống khác như YEAR.MONTH (2009.12) hoặc YEAR.RELEASE (2009.3). Nhưng thực sự bạn có lẽ tốt nhất gắn bó với MAJOR.MINOR trừ khi bạn có lý do chính đáng để không.

Chắc chắn không sử dụng bất cứ thứ gì không phù hợp với định dạng XY, vì nó sẽ gây khó khăn cho các bản phân phối, trang web thông báo, v.v. để làm việc với bạn và điều đó có thể ảnh hưởng nghiêm trọng đến sự phổ biến của dự án của bạn.

Sử dụng các nhánh và thẻ trong hệ thống kiểm soát phiên bản (tốt nhất là phân phối) của bạn để đánh dấu các số phiên bản nội bộ cụ thể có liên quan đến MAJORS và MINORS tương ứng.

Và vâng, 1.0 nên ổn định. Tất cả các bản phát hành phải ổn định, trừ khi chúng được đánh dấu alpha, beta hoặc RC. Sử dụng bảng chữ cái cho đã biết và chưa hoàn thành. Betas cho biết đã phá vỡ. RC cho "thử nó; bạn có thể sẽ phát hiện ra những thứ chúng tôi đã bỏ lỡ". Bất cứ điều gì mà không có một trong những điều này (tất nhiên, lý tưởng) sẽ được kiểm tra, được biết là tốt, có một hướng dẫn cập nhật, v.v.

Ngày nay, nó khá phổ biến để sử dụng số sửa đổi Subversion.

Nếu nó ở SVN thì tại sao không sử dụng số sửa đổi SVN?

Nếu bạn nhìn vào góc dưới bên phải của trang web này, bạn sẽ thấy số phiên bản Stack Overflow là số sửa đổi SVN.

Phiên bản là tùy thuộc vào bạn; Tôi đã đặt 1.0 lên phiên bản đầu tiên mà tôi tin tưởng. Bạn có thể muốn nhanh chóng theo dõi nó với các phiên bản khác, vì một số nhà cung cấp phần mềm đã cho 1.0 tiếng xấu.

Bạn muốn có một số cách buộc số phiên bản vào bản dựng chính xác được sử dụng, nhưng bạn có thể muốn nó đẹp và đơn giản cho người dùng cuối của bạn. Cân nhắc sử dụng số phiên bản tiêu chuẩn và gắn thẻ kho SVN với số phiên bản được bao gồm.

Mặc dù chỉ cần sử dụng số sửa đổi Subversion là tốt và đơn giản, nhưng nó sẽ xóa thông tin khỏi số phiên bản. Người dùng có thể coi đây là một điều xấu.

Tôi giả định rằng ứng dụng web của bạn sẽ có một số loại quy trình triển khai, do đó không phải mỗi sửa đổi trong Subversion thực sự được xuất bản. Vì không thể từ "bên ngoài" (từ góc nhìn của người dùng) để xác định khi nào các bản phát hành được thực hiện và bao nhiêu lần sửa đổi mã sẽ trải qua giữa chúng, nó làm cho các con số gần như ngẫu nhiên. Chúng sẽ tăng lên và tôi đoán có thể phỏng đoán một số khoảng cách so với hai phiên bản, nhưng không nhiều.

Số phiên bản cổ điển có xu hướng "kịch tính hóa" các bản phát hành, để người dùng có thể xây dựng một số loại kỳ vọng. Sẽ dễ dàng hơn khi nghĩ rằng "Tôi có phiên bản 1.0, bây giờ phiên bản 1.1 đã bổ sung thêm điều này và điều đó nghe có vẻ thú vị" hơn là nghĩ "hôm qua chúng tôi đã chạy phiên bản SO 2587, hôm nay là 3233, nó sẽ tốt hơn rất nhiều!".

Tất nhiên, quá trình tạo kịch tính này cũng có thể bị thổi phồng, với việc các công ty chọn số phiên bản nghe có vẻ thú vị hơn là bị thúc đẩy bởi sự khác biệt thực tế trong sản phẩm, tôi đoán sẽ đi cùng với số phiên bản sửa đổi một chút.

Lược đồ phiên bản: [chính]. [Nhỏ]. [Devrel] [mark]
[Major]: gia tăng nếu bạn có sự thay đổi mạnh mẽ trong phát triển.
[nhỏ]: gia tăng nếu bạn có một thay đổi nhỏ trong phát triển.
[devrel]: gia tăng nếu bạn có sửa lỗi. Đặt lại về 0 nếu chính ++ hoặc nhỏ ++.
[mark]: a, b hoặc rc: a là bản phát hành alpha, b là bản phát hành beta và RC là ứng cử viên phát hành. Lưu ý rằng các phiên bản như 1.3.57a hoặc 1.3.57b hoặc 1.3.57rc có trước phiên bản 1.3.57. Bắt đầu từ 0.0.0.

Chúng tôi đã dành quá nhiều thời gian để quyết định khi nào sẽ tăng phiên bản chính. Một số cửa hàng hiếm khi làm điều đó vì vậy bạn sẽ có các bản phát hành như 1.25.3 và những cửa hàng khác sẽ làm điều đó cho đến khi phát hành cho bạn 15.0

Tôi đã chán ngấy với điều đó và thuyết phục mọi người rằng số phát hành chính chỉ là năm và thứ yếu chỉ là một bản phát hành tuần tự trong năm. Người dùng dường như thích nó và không có gì lạ khi đưa ra số phiên bản tiếp theo.

Năm.Release.build

• năm = năm hiện tại
• phát hành = chuỗi # phát hành công khai với chức năng mới - đặt lại thành 1 mỗi năm
• build = tăng cho sửa lỗi và phát hành nội bộ

BIÊN TẬP

** Bây giờ, đây là một ứng dụng nội bộ được cải tiến liên tục **

Điều này có thể sẽ không hoạt động đối với các ứng dụng thương mại khi việc phát hành chính vào các thời điểm khác nhau trong năm cho các mục đích tài chính và tiếp thị là rất quan trọng.

Lý do tại sao câu hỏi này tồn tại là vì chúng tôi không có một cách thống nhất nào để thực hiện quản lý cấu hình.

Cách tôi muốn làm số phiên bản chỉ là số nguyên tăng từ 1. Tôi không muốn số phiên bản nhiều phần mà tôi sẽ phải giải thích hoặc tài liệu. Và tôi không muốn sử dụng số vòng quay SVN vì điều đó cũng sẽ cần một số giải thích.

Bạn sẽ cần một số tập lệnh phát hành trên SVN để thực hiện điều này

Tôi có rất ít kinh nghiệm trong khu vực. Tuy nhiên, đây là những gì tôi sẽ làm:

1. Chọn một sơ đồ để đánh số sửa đổi và bám vào nó. Hãy kiên định.
2. Mỗi thay đổi phiên bản nên đại diện cho một thay đổi đáng kể . Một thay đổi nhỏ có ý nghĩa như thế nào và mức độ thay đổi được phản ánh trong số phiên bản tùy thuộc vào bạn.

Tất nhiên, bạn chỉ có thể sử dụng số sửa đổi svn --- như nhiều người khác đã đề xuất !!!

Tôi hi vọng cái này giúp được.

Chúng tôi sử dụng cú pháp Major.minor.julian_date đơn giản.

Ở đâu;

• chính - Bản phát hành đầu tiên là 1 và sau đó khi chúng tôi giới thiệu các tính năng mới hoặc thay đổi quan trọng đến mức chúng không tương thích ngược tăng số này.
• nhỏ - Các cột mốc quan trọng phát hành. Đối với mỗi bản dựng được đẩy bởi sản xuất, con số này tăng lên.
• julian_date - Ngày Julian, bản dựng được đẩy lên QA.

Ví dụ về bản phát hành đầu tiên được đẩy lên QA vào ngày 1/15 là -> 1.0.015
Ví dụ về bản phát hành đầu tiên được đẩy lên Sản xuất vào ngày 3/4 là -> 1.1.063

Nó không hoàn hảo, nhưng tiện dụng khi chúng tôi đẩy các bản dựng lên QA gần hàng ngày.

Một số thông tin tốt ở đây:

Khi nào cần thay đổi phiên bản tệp / hội

Trước hết, phiên bản tập tin và phiên bản lắp ráp không cần phải trùng với nhau. Tôi khuyên các phiên bản tệp thay đổi theo từng bản dựng. Nhưng, đừng thay đổi các phiên bản lắp ráp với mỗi bản dựng để bạn có thể biết sự khác biệt giữa hai phiên bản của cùng một tệp; sử dụng phiên bản tập tin cho điều đó. Quyết định khi nào cần thay đổi phiên bản lắp ráp sẽ có một số thảo luận về các loại bản dựng để xem xét: vận chuyển và không vận chuyển.

Các bản dựng không vận chuyển Nói chung, tôi khuyên bạn nên giữ các phiên bản lắp ráp không vận chuyển giống nhau giữa các bản dựng vận chuyển. Điều này tránh được các vấn đề tải lắp ráp được đặt tên mạnh do sự không phù hợp của phiên bản. Một số người thích sử dụng chính sách của nhà xuất bản để chuyển hướng các phiên bản lắp ráp mới cho mỗi bản dựng. Tuy nhiên, tôi khuyên bạn nên chống lại điều đó đối với các bản dựng không vận chuyển: tuy nhiên, nó không tránh được tất cả các vấn đề về tải. Ví dụ: nếu đối tác sao chép ứng dụng của bạn, họ có thể không biết cài đặt chính sách của nhà xuất bản. Sau đó, ứng dụng của bạn sẽ bị hỏng cho họ, mặc dù nó chỉ hoạt động tốt trên máy của bạn.

Nhưng, nếu có trường hợp các ứng dụng khác nhau trên cùng một máy cần liên kết với các phiên bản lắp ráp khác nhau của bạn, tôi khuyên bạn nên cung cấp cho các bản dựng đó các phiên bản lắp ráp khác nhau để có thể sử dụng chính xác cho từng ứng dụng mà không phải sử dụng LoadFrom / etc.

Các bản dựng vận chuyển Về việc có nên thay đổi phiên bản đó cho các bản dựng vận chuyển hay không, tùy thuộc vào cách bạn muốn ràng buộc hoạt động cho người dùng cuối. Bạn có muốn các bản dựng này nằm cạnh nhau hoặc tại chỗ không? Có nhiều thay đổi giữa hai bản dựng không? Họ sẽ phá vỡ một số khách hàng? Bạn có quan tâm rằng nó phá vỡ chúng (hoặc bạn muốn buộc người dùng sử dụng các cập nhật quan trọng của bạn)? Nếu có, bạn nên xem xét tăng phiên bản lắp ráp. Nhưng, sau đó, một lần nữa, xem xét rằng làm điều đó quá nhiều lần có thể xả rác đĩa của người dùng với các hội đồng lỗi thời.

Khi bạn thay đổi phiên bản hội của bạn Để thay đổi phiên bản mã hóa cứng sang phiên bản mới, tôi khuyên bạn nên đặt biến cho phiên bản trong tệp tiêu đề và thay thế mã hóa cứng trong nguồn bằng biến. Sau đó, chạy bộ xử lý trước trong quá trình xây dựng để đưa vào phiên bản chính xác. Tôi khuyên bạn nên thay đổi phiên bản ngay sau khi giao hàng, không phải ngay trước đó, để có thêm thời gian để bắt lỗi do thay đổi.

Hoặc để sử dụng số phiên bản dấu phẩy số 'suy nghĩ' của bạn .. zB:

1.0.101 // sửa đổi 101, phát hành

hoặc 1.0.101-090303 // với ngày phát hành, tôi sử dụng cái này