Các số trong một phiên bản thường đại diện cho điều gì (ví dụ v1.9.0.1)?

Có thể đây là một câu hỏi ngớ ngẩn, nhưng tôi luôn giả sử mỗi số được mô tả bằng một khoảng thời gian đại diện cho một thành phần duy nhất của phần mềm. Nếu đó là sự thật, họ có bao giờ đại diện cho một cái gì đó khác nhau? Tôi muốn bắt đầu gán các phiên bản cho các bản dựng khác nhau của phần mềm của mình, nhưng tôi không thực sự chắc chắn nên cấu trúc nó như thế nào. Phần mềm của tôi có năm thành phần riêng biệt.

Trong phiên bản 1.9.0.1 :

• 1 : Sửa đổi lớn (Giao diện người dùng mới, nhiều tính năng mới, thay đổi khái niệm, v.v.)

• 9 : Sửa đổi nhỏ (có thể thay đổi hộp tìm kiếm, thêm 1 tính năng, bộ sưu tập sửa lỗi)

• 0 : Phát hành sửa lỗi

• 1 : Xây dựng số (nếu được sử dụng) Tại sao bạn thấy .NET framework sử dụng cái gì đó như 2.0.4.2709

Bạn sẽ không tìm thấy nhiều ứng dụng đi xuống bốn cấp độ, 3 thường là đủ.

Có đặc tả Phiên bản ngữ nghĩa

Đây là bản tóm tắt của phiên bản 2.0.0:

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.

Nó có thể rất độc đoán, và khác nhau từ sản phẩm này sang sản phẩm khác. Ví dụ: với bản phân phối Ubuntu, 8.04 đề cập đến 2008.April

Thông thường, hầu hết các số (chính) bên trái chỉ ra một bản phát hành chính và bạn càng đi sang bên phải, thay đổi liên quan càng nhỏ.

Major.minor [.maintenance [.build]]

http://en.wikipedia.org/wiki/Software_versioning#Numeric

Càng nhiều điểm, phát hành càng nhỏ. Không có tiêu chuẩn vững chắc thực sự ngoài điều đó - có thể có nghĩa là những điều khác nhau dựa trên những gì người bảo trì dự án quyết định.

WordPress, ví dụ, đi dọc theo các dòng sau:

1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...

1.6 đến 2.0 sẽ là một bản phát hành lớn - các tính năng, thay đổi giao diện, thay đổi lớn đối với API, phá vỡ một số mẫu và plugin 1.6, v.v. 2.0 đến 2.0.1 sẽ là một bản phát hành nhỏ - có thể sửa lỗi bảo mật. 2.0.2 đến 2.1 sẽ là một bản phát hành quan trọng - nói chung là các tính năng mới.

Các số có thể hữu ích như được mô tả bởi các câu trả lời khác, nhưng hãy xem xét làm thế nào chúng cũng có thể khá vô nghĩa ... Sun, bạn biết SUN, java: 1.2, 1.3, 1.4 1.5 hoặc 5 rồi 6. Trong các phiên bản Apple II cũ tốt, Mete Một cái gì đó. Ngày nay, mọi người đang từ bỏ số phiên bản và đi với những cái tên ngớ ngẩn như "Feisty fig" (hoặc đại loại như thế) và "hardy heron" và "europa" và "ganymede". Tất nhiên, điều này ít hữu ích hơn bởi vì, bạn sẽ hết mặt trăng của sao Mộc trước khi bạn ngừng thay đổi chương trình, và vì không có thứ tự rõ ràng nào bạn không thể biết cái nào mới hơn.

Trong phiên bản v1.9.0.1: Đây là lược đồ phiên bản rõ ràng được sử dụng khi bạn không muốn sử dụng tên cho bản phát hành trước hoặc xây dựng như -alpha, -beta.

1: Phiên bản chính có thể phá vỡ tính tương thích ngược

9: Thêm các tính năng mới để hỗ trợ ứng dụng của bạn cùng với khả năng tương thích ngược với phiên bản trước.

0: Một số sửa lỗi nhỏ

1: Số bản dựng (Số phát hành trước)

nhưng ngày nay, bạn sẽ không tìm thấy sơ đồ phiên bản như vậy. Tham khảo Phiên bản ngữ nghĩa [semver2.0] https://semver.org/

Số phiên bản thường không đại diện cho các thành phần riêng biệt. Đối với một số người / phần mềm, các con số khá tùy tiện. Đối với những người khác, các phần khác nhau của chuỗi số phiên bản đại diện cho những thứ khác nhau. Ví dụ: một số hệ thống tăng các phần của số phiên bản khi định dạng tệp thay đổi. Vì vậy, V 1.2.1 là định dạng tệp tương thích với tất cả các phiên bản V 1.2 khác (1.2.2, 1.2.3, v.v.) nhưng không phải với V 1.3. Cuối cùng, tùy thuộc vào kế hoạch bạn muốn sử dụng.

Thông thường của nó:

MajorVersion.MinorVersion.Revision.Build

Nó phụ thuộc, nhưng đại diện điển hình là của Major.minor.release.build .

Ở đâu:

• chính là phiên bản phát hành chính của phần mềm của bạn, hãy nghĩ .NET 3.x
• nhỏ là phiên bản phát hành nhỏ của phần mềm của bạn, hãy nghĩ .NET x.5
• phát hành là phiên bản của phiên bản đó, thông thường các lỗi sẽ tăng điều này
• bản dựng là một số biểu thị số lượng bản dựng bạn đã thực hiện.

Vì vậy, ví dụ 1.9.0.1, có nghĩa là phiên bản 1.9 của phần mềm của bạn, theo phiên bản 1.8 và 1.7, v.v ... trong đó 1.7, 1.8 và 1.9 theo một cách nào đó thường thêm một lượng nhỏ các tính năng mới bên cạnh các lỗi. Vì là xx0.x, đây là bản phát hành đầu tiên của 1.9 và là bản dựng đầu tiên của phiên bản đó.

Bạn cũng có thể tìm thấy thông tin tốt về bài viết Wikipedia về chủ đề này .

Major.Minor.Bugs

(Hoặc một số biến thể về điều đó)

Lỗi thường là sửa lỗi không có chức năng mới.

Nhỏ là một số thay đổi bổ sung chức năng mới nhưng không thay đổi chương trình theo bất kỳ cách chính nào.

Chính là một thay đổi trong chương trình phá vỡ chức năng cũ hoặc lớn đến mức bằng cách nào đó thay đổi cách người dùng nên sử dụng chương trình.

Mọi người chọn những gì họ muốn làm với những con số này. Tôi đã cố gắng gọi các bản phát hành abc vì dù sao nó cũng khá ngớ ngẩn. Điều đó đang được nói, những gì tôi đã thấy trong hơn 25 năm phát triển có xu hướng hoạt động theo cách này. Giả sử số phiên bản của bạn là 1.2.3.

"1" cho biết bản sửa đổi "chính". Thông thường đây là một bản phát hành ban đầu, một bộ tính năng lớn thay đổi hoặc viết lại các phần quan trọng của mã. Khi bộ tính năng được xác định và ít nhất được triển khai một phần, bạn chuyển đến số tiếp theo.

"2" chỉ ra một bản phát hành trong một loạt. Thông thường chúng tôi sử dụng vị trí này để bắt kịp các tính năng không có trong phiên bản chính cuối cùng. Vị trí này (2) hầu như luôn chỉ ra một tính năng thêm, thường là với các sửa lỗi.

"3" trong hầu hết các cửa hàng cho thấy bản phát hành bản vá / sửa lỗi. Hầu như không bao giờ, ít nhất là về mặt thương mại, điều này cho thấy một tính năng bổ sung quan trọng. Nếu các tính năng hiển thị ở vị trí 3 thì có lẽ là do ai đó đã kiểm tra thứ gì đó trước khi chúng tôi biết rằng chúng tôi phải thực hiện một bản phát hành sửa lỗi.

Ngoài vị trí "3"? Tôi không biết tại sao mọi người lại làm điều đó, nó trở nên khó hiểu hơn.

Đáng chú ý là một số OSS ngoài kia ném tất cả những thứ này ra khỏi wack. Ví dụ, phiên bản Trac 10 thực sự là 0.10.XX Tôi nghĩ rằng rất nhiều người trong thế giới OSS thiếu tự tin hoặc chỉ không muốn thông báo rằng họ đã phát hành chính.

Từ tệp C # hộiInfo.cs bạn có thể thấy như sau:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]

phát hành.major.minor.revision sẽ là dự đoán của tôi.
Nhưng nó có thể khác nhau rất nhiều giữa các sản phẩm.

Major.minor.point.build thường. Chính và phụ là tự giải thích, điểm là một bản phát hành cho một vài lỗi nhỏ và bản dựng chỉ là một định danh bản dựng.

Vâng Các bản phát hành chính bổ sung các tính năng lớn, mới, có thể phá vỡ tính tương thích hoặc có các phụ thuộc khác nhau đáng kể, v.v.

Các bản phát hành nhỏ cũng thêm các tính năng, nhưng chúng là các phiên bản được chuyển xuống đôi khi nhỏ hơn từ bản phát hành chính beta.

Nếu có thành phần số phiên bản thứ ba, nó thường dành cho các lỗi quan trọng và sửa lỗi bảo mật. Nếu có nhiều hơn, nó thực sự phụ thuộc rất nhiều vào sản phẩm mà thật khó để đưa ra câu trả lời chung chung.

Mô hình của bản phát hành chính.minor phát hành. Sửa lỗi là khá phổ biến, tôi nghĩ vậy.

Trong một số hợp đồng hỗ trợ doanh nghiệp có $$$ (hoặc vi phạm trách nhiệm hợp đồng) liên quan đến cách phát hành cụ thể. Ví dụ, một hợp đồng có thể cho phép khách hàng sử dụng một số lượng phát hành chính trong một khoảng thời gian hoặc hứa rằng sẽ có ít hơn x số lượng phát hành nhỏ trong một khoảng thời gian hoặc hỗ trợ sẽ tiếp tục có sẵn cho nhiều người phát hành. Tất nhiên, cho dù có bao nhiêu từ được đưa vào hợp đồng để giải thích bản phát hành chính là gì so với bản phát hành nhỏ, nó luôn mang tính chủ quan và sẽ luôn có những vùng màu xám - dẫn đến khả năng nhà cung cấp phần mềm có thể chơi trò chơi hệ thống đánh bại các điều khoản hợp đồng như vậy.

Mọi người không luôn nhận ra sự khác biệt tinh tế giữa các số phiên bản như 2.1, 2.0.1 hoặc 2.10 - hãy hỏi một người hỗ trợ kỹ thuật bao nhiêu lần họ gặp rắc rối với việc này. Các nhà phát triển được định hướng chi tiết và quen thuộc với các cấu trúc phân cấp, vì vậy đây là một điểm mù đối với chúng tôi.

Nếu có thể, hãy để lộ số phiên bản đơn giản hơn cho khách hàng của bạn.

Trong trường hợp thư viện, số phiên bản cho bạn biết về mức độ tương thích giữa hai bản phát hành, và do đó việc nâng cấp sẽ khó khăn như thế nào.

Một bản phát hành sửa lỗi cần phải duy trì khả năng tương thích nhị phân, nguồn và tuần tự hóa.

Các bản phát hành nhỏ có nghĩa là những thứ khác nhau cho các dự án khác nhau, nhưng thông thường chúng không cần phải duy trì khả năng tương thích nguồn.

Số phiên bản chính có thể phá vỡ cả ba hình thức.

Tôi đã viết thêm về lý do ở đây .

Một sự kết hợp của chính, nhỏ, vá, xây dựng, vá bảo mật, vv

Hai cái đầu tiên là chính & phụ - phần còn lại sẽ phụ thuộc vào dự án, công ty và đôi khi là cộng đồng. Trong hệ điều hành như FreeBSD, bạn sẽ có 1.9.0.1_number để thể hiện bản vá bảo mật.

Phụ thuộc một chút vào ngôn ngữ, ví dụ Delphi và C # có ý nghĩa khác nhau.

Thông thường, hai số đầu tiên tương ứng với một phiên bản chính và một phiên bản nhỏ, tức là 1.0 cho bản phát hành thực đầu tiên, 1.1 cho một số lỗi quan trọng và các tính năng mới nhỏ, 2.0 cho bản phát hành tính năng mới lớn.

Số thứ ba có thể đề cập đến một phiên bản "thực sự nhỏ" hoặc sửa đổi. 1.0.1 chỉ là một lỗi rất nhỏ đối với 1.0.0 chẳng hạn. Nhưng nó cũng có thể mang số Sửa đổi từ Hệ thống Kiểm soát Nguồn của bạn hoặc số tăng dần không ngừng tăng lên với mỗi bản dựng. Hoặc một Datestamp.

Một chút chi tiết ở đây . "chính thức", trong .net, 4 số là "Major.Minor.Build.Revision", trong khi ở Delphi có "Major.Minor.Release.Build". Tôi sử dụng "Major.Minor.ReallyMinor.SubversionRev" cho phiên bản của mình.

Nói chung, số ở định dạng của phiên bản.major.minor.hotfix, không phải là các thành phần nội bộ riêng lẻ. Vì vậy, v1.9.0.1 sẽ là phiên bản 1, bản phát hành chính 9 (của v1), bản phát hành nhỏ (của v1.9) 0, bản sửa lỗi nóng 1 của (v1.9.0).

Số đầu tiên thường được gọi là số phiên bản chính. Về cơ bản, nó được sử dụng để biểu thị những thay đổi đáng kể giữa các bản dựng (tức là khi bạn thêm nhiều tính năng mới, bạn sẽ tăng phiên bản chính). Các thành phần với các phiên bản chính khác nhau từ cùng một sản phẩm có thể không tương thích.

Số tiếp theo là số phiên bản nhỏ. Nó có thể đại diện cho một số tính năng mới, hoặc một số sửa lỗi hoặc thay đổi kiến ​​trúc nhỏ. Các thành phần từ cùng một sản phẩm khác nhau theo số phiên bản nhỏ có thể hoặc không thể hoạt động cùng nhau và có lẽ không nên.

Tiếp theo thường được gọi là số xây dựng. Điều này có thể được tăng lên hàng ngày hoặc với mỗi bản dựng "được phát hành" hoặc với mỗi bản dựng. Có thể chỉ có sự khác biệt nhỏ giữa hai thành phần chỉ khác nhau về số lượng bản dựng và thường có thể hoạt động tốt với nhau.

Số cuối cùng thường là số sửa đổi. Thông thường, điều này được sử dụng bởi quy trình xây dựng tự động hoặc khi bạn thực hiện các bản dựng ném "một lần" để thử nghiệm.

Khi bạn tăng số phiên bản của bạn là tùy thuộc vào bạn, nhưng chúng phải luôn tăng hoặc giữ nguyên . Bạn có thể có tất cả các thành phần chia sẻ cùng một số phiên bản hoặc chỉ tăng số phiên bản trên các thành phần đã thay đổi.

Số phiên bản của một phần mềm phức tạp đại diện cho toàn bộ gói và độc lập với số phiên bản của các bộ phận. Phiên bản Gizmo 3.2.5 có thể chứa phiên bản Foo 1.2.0 và phiên bản Bar 9.5.4.

Khi tạo số phiên bản, sử dụng chúng như sau:

1. Số đầu tiên là phát hành chính. Nếu bạn thực hiện thay đổi đáng kể cho giao diện người dùng hoặc cần phá vỡ các giao diện hiện có (để người dùng của bạn sẽ phải thay đổi mã giao diện của họ), bạn nên chuyển sang phiên bản chính mới.

2. Số thứ hai sẽ chỉ ra rằng các tính năng mới đã được thêm vào hoặc một cái gì đó hoạt động khác nhau trong nội bộ. (Ví dụ: cơ sở dữ liệu Oracle có thể quyết định sử dụng một chiến lược khác để truy xuất dữ liệu, làm cho hầu hết mọi thứ nhanh hơn và một số thứ chậm hơn.) Các giao diện hiện tại sẽ tiếp tục hoạt động và giao diện người dùng nên được nhận biết.

3. Việc đánh số phiên bản hơn nữa tùy thuộc vào người viết phần mềm - Oracle sử dụng năm nhóm (!), Tức là. một phiên bản Oracle giống như 10.1.3.0.5. Từ nhóm thứ ba trở xuống, bạn chỉ nên giới thiệu các lỗi hoặc thay đổi nhỏ trong chức năng.

những cái khác nhau ít hơn sẽ là hai cái đầu tiên, đối với Major.minor, sau đó nó có thể là bất cứ thứ gì từ xây dựng, sửa đổi, phát hành, cho đến bất kỳ thuật toán tùy chỉnh nào (như trong một số sản phẩm MS)

Mỗi tổ chức / nhóm đều có tiêu chuẩn riêng. Điều quan trọng là bạn tuân theo bất kỳ ký hiệu nào bạn chọn nếu không khách hàng của bạn sẽ bối rối. Phải nói rằng tôi đã sử dụng bình thường 3 số:

x.yz.bbbbb. Trong đó: x: là phiên bản chính (các tính năng mới chính) y: là số phiên bản phụ (tính năng mới nhỏ, cải tiến nhỏ mà không thay đổi giao diện người dùng) z: là gói dịch vụ (về cơ bản giống như xy nhưng có một số lỗi sửa lỗi bbbb: là số bản dựng và chỉ thực sự hiển thị từ "hộp giới thiệu" với các chi tiết khác để hỗ trợ khách hàng. bbbb là định dạng miễn phí và mọi sản phẩm đều có thể sử dụng riêng.

Đây là những gì chúng tôi sử dụng:

1. Số đầu tiên = kỷ nguyên hệ thống tổng thể. Thay đổi vài năm một lần và thường đại diện cho một thay đổi cơ bản trong công nghệ, hoặc các tính năng của khách hàng hoặc cả hai.
2. Số thứ hai = sửa đổi lược đồ cơ sở dữ liệu. Sự gia tăng số lượng này đòi hỏi phải di chuyển cơ sở dữ liệu và do đó, một sự thay đổi đáng kể (hoặc sao chép hệ thống và do đó thay đổi cấu trúc cơ sở dữ liệu đòi hỏi một quá trình nâng cấp cẩn thận). Đặt lại về 0 nếu số đầu tiên thay đổi.
3. Số thứ ba = phần mềm chỉ thay đổi. Điều này thường có thể được thực hiện trên máy khách theo cơ sở máy khách vì lược đồ cơ sở dữ liệu không thay đổi. Đặt lại về 0 nếu số thứ hai thay đổi.
4. Số phiên bản lật đổ. Chúng tôi tự động điền vào bản dựng này bằng công cụ TortoiseSVN. Con số này không bao giờ đặt lại mà liên tục tăng. Sử dụng điều này, chúng tôi luôn có thể tạo lại bất kỳ phiên bản.

Hệ thống này đang phục vụ chúng tôi tốt vì mọi số đều có chức năng rõ ràng và quan trọng. Tôi đã thấy các đội khác vật lộn với câu hỏi số chính / số phụ (thay đổi lớn như thế nào) và tôi không thấy lợi ích cho điều đó. Nếu bạn không cần theo dõi các sửa đổi cơ sở dữ liệu, chỉ cần chuyển đến số phiên bản 3 hoặc 2 chữ số, và làm cho cuộc sống dễ dàng hơn!

phiên bản: v1.9.0.1

Ở đâu-

. v là viết tắt của phiên bản. Nó thay đổi theo từng công ty tùy thuộc vào danh pháp được thông qua trong tổ chức của mình. Nó có thể im lặng trong một số tổ chức như 1.9.0.1

. 1 cho biết phiên bản chính, sẽ được cập nhật về Sửa đổi kiến ​​trúc trong ngăn xếp ứng dụng, cơ sở hạ tầng (nền tảng) hoặc giao diện mạng được hiển thị

. 9 incates nhỏ, sẽ được cập nhật vào hoạt động như thêm các thành phần mới như ui, api, cơ sở dữ liệu, v.v; theo một kiến ​​trúc cụ thể

. 0 cho biết tính năng, sẽ được cập nhật trên bất kỳ cải tiến nào trên các thành phần hiện có (ui, api, cơ sở dữ liệu, v.v.)

. 1 chỉ ra bộ đếm xây dựng trên tất cả các pha chính, phụ và tính năng. Nó cũng bao gồm các hotfix phát hành bài sản xuất.