Ngày là số phiên bản phần mềm

Các nhà phát triển phần mềm thường không sử dụng ngày làm số phiên bản, mặc dù định dạng YYYYMMDD (hoặc phương sai của nó) trông đủ vững chắc để sử dụng. Có bất cứ điều gì sai với kế hoạch đó? Hoặc nó chỉ áp dụng cho 'loại' phần mềm giới hạn (như sản xuất nội bộ)?

Đây là điều mà bạn sẽ phải xem xét từ một vài góc độ khác nhau khi bạn cần tính đến nhu cầu của người dùng cũng như nhu cầu của phần mềm và nhà phát triển.

Nói chung, khách hàng của bạn sẽ không quan tâm lắm đến số phiên bản của phần mềm sẽ là gì miễn là họ biết họ đang chạy một cái gì đó mới hơn (ví dụ: Sản phẩm 2012 mới hơn Sản phẩm 2010) và họ biết điều đó được cập nhật nếu có các bản vá có thể được triển khai (ví dụ: Sản phẩm 2012, Cập nhật 10). Như vậy, từ quan điểm xây dựng thương hiệu khách hàng, tôi có xu hướng thích một bản phát hành có tên (ví dụ: Windows XP, Windows Vista) theo sau là một số bản vá lỗi nghiêm ngặt có thể được cài đặt bởi người dùng.

Mặc dù vậy, việc viết phần mềm kiểm tra những thứ dễ dàng cho người dùng có xu hướng làm cho mã dưới mui xe khó viết hơn nhiều. Vì vậy, tôi có xu hướng thích Major.Minorsơ đồ phiên bản đơn giản nếu chỉ vì bạn có thể thực hiện so sánh số đơn giản để kiểm tra xem có gì cập nhật như sau:

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...

Tuy nhiên, để đặt điều này trong một chút bối cảnh, tôi thường không quan tâm số lượng nhỏ nhận được (ví dụ 1.1024) lớn như thế nào, cho phép hệ thống trên tiếp tục chạy thành công. Nói chung, các số sửa đổi chỉ đáng quan tâm đối với sự phát triển nội bộ và tôi thực sự thậm chí chưa thực sự thấy chúng ảnh hưởng đến những thứ vượt xa việc chỉ cung cấp cho mọi thứ một số bổ sung để theo dõi.

Tuy nhiên, hai lược đồ trên thực sự chỉ không áp dụng cho các môi trường sử dụng triển khai liên tục (ví dụ: Stack Exchange), nơi tôi có xu hướng thích một số ngày theo sau là số sửa đổi dường như được sử dụng trên Stack Exchange các trang web. Lý do cho điều này là các phiên bản sẽ thay đổi quá thường xuyên trong môi trường triển khai liên tục và bạn có thể có nhiều phiên bản mã tăng lên trong cùng một ngày, điều này chứng minh số sửa đổi và ngày hiện tại cũng tốt như bất kỳ điều gì để phá vỡ mọi thứ thậm chí nhiều hơn Về lý thuyết, bạn chỉ có thể sử dụng số sửa đổi cho tất cả mọi thứ, nhưng việc sử dụng ngày hiện tại cho phép bạn theo dõi các cột mốc quan trọng trong nội bộ có thể khiến mọi thứ trở nên dễ dàng hơn để thảo luận.

Vấn đề với việc sử dụng một ngày, là các thông số kỹ thuật được viết dựa trên các số đếm thay vì một ngày khi đến hạn.

"Phần chức năng này là do được phát hành 1. Phần chức năng khác là do được phát hành 2."

Bạn không thể đề cập đến một ngày trong thông số kỹ thuật, vì ngày phát hành có thể bị bỏ lỡ.

Nếu bạn không có một quy trình chính thức như vậy cần các bản phát hành khác nhau được xác định trước, sử dụng ngày là tốt; bạn không cần thêm số khác vào hỗn hợp.

Số phiên bản không có khả năng chứa ngày, vì bối cảnh của chúng được liên kết với thông số kỹ thuật.
Số bản dựng có thể chứa ngày, vì bối cảnh của chúng được liên kết với khi quá trình xây dựng diễn ra.

Mặc dù phương pháp này có lợi ích như bạn mô tả, nhưng có một số hạn chế nhất định nếu bạn sử dụng ngày làm số phiên bản:

• Phiên bản dựa trên ngày là phẳng. Với v2.1.3, bạn có thể thấy số phiên bản, số phiên bản phụ và số phiên bản phụ. Với 20110119 bạn chỉ có thể nhìn thấy khi nó được viết. Bạn có thể nhóm các phiên bản dựa trên ngày của mình theo tháng, nhưng nó vẫn không cho bạn biết bất cứ điều gì. Bạn có thể có vài tháng chậm sửa lỗi nhỏ và sau đó hai tuần mã hóa nặng dẫn đến một bản phát hành lớn. Ngày không cho bạn biết rằng, số phiên bản thông thường làm.

• Nếu bạn thực sự cần thay đổi phiên bản hàng ngày và có thể phát hành số, điều đó có thể cho thấy rằng bạn không có quy trình phát hành phù hợp, nhưng thay vào đó mọi người sẽ thay đổi công cụ và quảng bá nó đến các máy chủ sản xuất bất cứ khi nào họ muốn. Nếu vậy, bạn có vấn đề với quy trình và sử dụng lược đồ số phiên bản khác nhau sẽ không giải quyết được.

Các phiên bản thường được sử dụng để truyền đạt thông tin về mức độ khác nhau của một phiên bản phần mềm so với phiên bản trước. Vì vậy, ví dụ, nếu bạn nâng cấp từ 1.0 lên 2.0 của Acme, đó là một nâng cấp lớn, theo lý thuyết mang theo những thay đổi lớn.

Mặt khác, bản nâng cấp từ 1.0 lên 1.1 là một bản nâng cấp nhỏ và trên lý thuyết mang những thay đổi nhỏ, gia tăng và sửa lỗi.

Điều này sẽ khó biểu diễn theo định dạng ngày, mặc dù bạn có thể sử dụng hỗn hợp. Ví dụ: v1.0.YYYY.MMDĐ

Không lặp lại ý tưởng tốt từ các câu trả lời khác, tôi có một vấn đề trong đầu chưa được giải quyết.

Nếu bạn tình cờ thực hiện một ngã ba, giữa một phiên bản cũ hơn để tương thích ngược và một phiên bản mới để hiện đại hóa không tương thích, bạn không thể phân biệt chúng thông qua số phiên bản.

Ví dụ, nhân Linux đã được chia rẽ vào khoảng năm 2000 thành nhánh 2.4.x cũ, có lẽ vẫn được hỗ trợ cho đến ngày nay và được tính là 2.4.199, trong khi phiên bản mới đã là 2.6 trong nhiều năm, và là 2.6.32 cho các hệ thống cũ, nhưng 3.2 cho các hạt nhân mới nhất.

Nếu bạn có tài liệu về các bản phát hành của mình, bạn sẽ nhân đôi thông tin và nói với mọi người, phiên bản 20120109 đã đến vào năm 2012 lúc 01/09. Ừm Nhưng những gì, nếu có một phát hiện lỗi vào phút cuối và một bản phát hành bị trì hoãn trong một tuần, nhưng tài liệu, nơi tên được đề cập, đã sẵn sàng, có thể được in, thông tin báo chí được đưa ra và vân vân. Bây giờ bạn có một sự khác biệt là có vấn đề, nếu phiên bản 20120109 đến vào ngày 2012/01/13.

Trong SQL, câu hỏi liệu ID có nên mang thông tin ngữ nghĩa thường được thảo luận hay không và kết quả luôn là: tránh nó như địa ngục! Bạn đang tạo ra một sự phụ thuộc không cần thiết. Nó không có ích.

Ubuntu với sơ đồ 04/10 đã gặp sự cố vào năm 2006, khi phiên bản 6.04 bị trì hoãn và trở thành 6.06. Năm 3000 sẽ sớm có vấn đề tiếp theo! :)

Có nhiều gói phần mềm thực sự sử dụng ngày như một phiên bản. Ubuntu xuất hiện trong đó phiên bản của họ là YY.MM. Và số bản dựng cho các sản phẩm Microsoft Office cũng là một mã hóa của ngày xây dựng. Jeff Atwood đã viết một bài đăng trên blog Mã hóa Kinh dị về đánh số phiên bản , bao gồm khuyến nghị này:

Bất cứ khi nào có thể, hãy sử dụng ngày đơn giản thay vì số phiên bản, đặc biệt là tên công khai của sản phẩm. Và nếu bạn hoàn toàn, tích cực phải sử dụng số phiên bản trong nội bộ, hãy đặt ngày tháng bằng cách nào: hãy chắc chắn mã hóa ngày của bản dựng ở đâu đó trong số phiên bản của bạn.

Theo tôi, điều đó không quan trọng miễn là bạn nhất quán và có thể đi từ số phiên bản xây dựng (bất kể đó là gì) và nhớ lại tất cả các tạo phẩm đã đi vào bản dựng đó từ hệ thống kiểm soát phiên bản của bạn. Người dùng thường không quan tâm đến thông tin phiên bản, mà là chức năng do hệ thống cung cấp. Thông tin phiên bản chỉ có giá trị thực sự cho các nhà phát triển.

Sử dụng phiên bản ngữ nghĩa - theo cách đó, bạn có một số ý tưởng về loại thay đổi được thực hiện giữa các phiên bản mà không phải kiểm tra chính mã: http://semver.org/

Sử dụng số Phiên bản là một cách để cho thấy mức độ thay đổi LỚN

Ví dụ 2.4.3 có thể có nghĩa là phiên bản 2 là thay đổi lớn đối với toàn bộ hệ thống. .4 là một bản cập nhật nhỏ. và .3 cuối cùng là một sửa lỗi nhỏ cho phiên bản đó. Bằng cách đó, nó dễ dàng nhận ra đã thay đổi bao nhiêu giữa mỗi phiên bản.

Có nói rằng tôi vẫn thấy nhiều người sử dụng ngày sửa đổi hoặc số sửa đổi SCM làm số phiên bản miễn là bạn có cách nào đó để theo dõi lại để hỗ trợ ghi chú phát hành và tài liệu về những gì trong phạm vi cho bản phát hành đó không có vấn đề thực sự.

Một số câu trả lời tốt đã có ở đây, nhưng tôi muốn chỉ ra một trường hợp sử dụng ngày có ý nghĩa hoàn hảo: thư viện nhỏ hoặc đoạn mã có thể được cập nhật thường xuyên nhưng trong các bit nhỏ không có phiên bản đơn lẻ nào khác biệt so với trước một.

Nói cách khác, tôi đang nói về các tình huống không có "số phiên bản" thực tế nhưng về cơ bản là một loại kho lưu trữ gần như hàng ngày.

Khi tôi gặp loại nội dung này, tôi thường hoan nghênh sự lựa chọn vì nó hữu ích hơn cho tôi khi biết rằng tôi đang sử dụng một tập lệnh / lib tương đối hiện tại thay vì một phiên bản cụ thể.

Ngày tháng như một số phiên bản là tốt cho tiếp thị. Nếu mọi người đang sử dụng "Windows NT 5.0", họ có thể không nhận ra nó đã lỗi thời. Nhưng nếu mọi người vẫn đang sử dụng "Windows 2000", họ sẽ biết ngay đó là HĐH 12 tuổi và được khuyến khích nâng cấp.

Tuy nhiên, điều này làm cho việc phân biệt giữa các cập nhật "chính" và "nhỏ" trở nên khó khăn hơn.

Vấn đề với việc sử dụng Ngày làm số phiên bản

Các câu trả lời ở đây là tốt, nhưng tôi không thấy ai giải quyết mối quan tâm này bằng cách sử dụng ngày: Người dùng không thể xác định tần suất sửa đổi đã được thực hiện.

Điều tôi đang cố gắng nói là tôi có thể nói rằng Windows 3.1 và Windows 7 cách xa nhau ... và có lẽ không tương thích. Windows 95 và Windows 2000 cho tôi biết không có gì nhiều hơn năm mà sản phẩm được giới thiệu.

Ví dụ, với Python, tôi biết rằng phiên bản 2.7.2 đã phát triển từ 2.4.6. Nếu tôi nhìn xa hơn, tôi thấy phiên bản 2.4.6 được phát hành vào ngày 19 tháng 12 năm 2008; và phiên bản 2.7.2 đó đã được phát hành vào ngày 11 tháng 6 năm 2011. Từ đó, tôi có thể đưa ra ý kiến ​​về tính ổn định (nghĩa là tần suất phát hành) của sản phẩm.

Thay vào đó, nếu Python đã sử dụng ngày phát hành, tôi không thể biết các sản phẩm này có thể được kết nối như thế nào. Sự nhầm lẫn sẽ dẫn đến, bởi vì Python 3.1.4 cũng được phát hành vào ngày 11 tháng 6 năm 2011 (giống như Python 2.7.2).

Nói tóm lại, tôi không nghĩ rằng, bản thân nó, phiên bản ngày tháng là có giá trị.

Tôi không thích ý tưởng này, vì những lý do đã được người khác mô tả. Chỉ cần sử dụng lược đồ Major.minor.ormsfix - có một lý do tại sao hầu hết mọi người làm theo cách này.

Nhưng bất cứ điều gì bạn làm: chọn một sơ đồ đặt tên phiên bản và tuân theo nó . Đừng làm như Windows, nơi họ thay đổi lược đồ với mỗi bản phát hành. Và đừng làm như Android, trong đó mỗi bản phát hành có số phiên bản API (8), số phiên bản dành cho tiếp thị (2.2) và tên ngu ngốc (Froyo).

Ngày là một phiên bản

Nếu sản phẩm của bạn không được bán thì chỉ cần sử dụng ngày là tốt và có thể hữu ích. Nếu bạn bán nó và nâng cấp cho khách hàng, họ muốn mua một mô hình với một bộ tính năng cụ thể. Việc bán chúng khi nâng cấp sẽ dễ dàng hơn nhiều nếu mẫu xe này có tên rõ ràng, không quan trọng nó là gì nhưng ví dụ không ai thực sự mua chiếc xe Ford ngày 20 tháng 1 năm 2012 mà họ muốn chiếc Kia Model nào. Điều tương tự cũng đúng với phần mềm. Đặt tên và phiên bản mô hình cứng có nghĩa là nó có các tính năng khác với phiên bản cũ hơn. Đối với tôi chỉ là một ngày không làm điều đó, nó nói rằng tôi đã thực hiện nó sau đó, không phải nó có thể có các tính năng mới.

Đề án chúng tôi sử dụng

Tôi không tuyên bố rằng hệ thống của chúng tôi, tạo ra một thương hiệu rõ ràng như trên. Bây giờ chúng tôi sử dụng một sơ đồ bốn phần. Một số phiên bản, tiểu bang, ngày và tổng kiểm tra.

1200_GLD_120120_F0D1

Điều này có thể vượt qua đỉnh nhưng nó cho phép chúng tôi có một số phiên bản xây dựng cho phiên bản 1200 mà các kỹ sư của chúng tôi có thể sử dụng và chúng tôi phân biệt giữa chúng theo ngày. Nhà nước nói với mọi người nếu đó là phiên bản thử nghiệm nội bộ, xây dựng bản vá khách hàng hoặc phát hành vàng. Tổng kiểm tra là mới, nó cho phép một kỹ sư hoặc khách hàng xác minh rằng họ thực sự đã tải xuống chính xác từ phân phối của chúng tôi.

Vì vậy, chúng tôi có thể có một chuỗi

1200_TST_120110_EF45
1200_GLD_120120_F0D1
1201_FIX_120125_123E
1201_TST_120130_31A5
1201_TST_120131_FDFD

Chúng tôi thường chỉ đề cập đến các số phiên bản chính cho khách hàng, tức là "12", nhưng một khách hàng sẽ nhận được phiên bản vàng mới nhất là 12, tức là 1200_GLD_120120_F0D1 trừ khi họ cần Khắc phục.

Giả sử một số khách hàng sử dụng phiên bản hai của sản phẩm của bạn và một số khách hàng đã nâng cấp lên phiên bản ba và việc nâng cấp đó không phải là một quyết định nhẹ nhàng.

Giả sử phiên bản cuối cùng của phiên bản hai là 2.3.2 và phiên bản ba là 3.0.3. Bây giờ bạn tìm thấy một lỗ hổng hoàn toàn cần phải được sửa chữa, vì vậy bạn phát hành phiên bản 2.3.3 và 3.0.4 trong cùng một ngày. Bạn có thể thấy làm thế nào ngày phát hành là hoàn toàn không liên quan? Bạn có thể đã ngừng làm việc trên phiên bản hai vào năm 2013 và chỉ phát hành một số sửa lỗi thiết yếu kể từ đó. Ngày không liên quan so với số phiên bản.

Tôi nghĩ rằng nó hoạt động tốt. Tôi sử dụng nó cho một số phần mềm nội bộ (yyyy.mm.dd) và cho một số phần mềm nguồn mở mà tôi đã phát hành.

Nó có thể không hoạt động trong mọi trường hợp.

Về mặt kỹ thuật Nó không thể sử dụng ngày cho số phiên bản, nhưng nó có thể hiển thị số ngày cho khách hàng. Ví dụ: macOS 16.7.23 --- có nghĩa là: 23/7/2016

Tôi nghĩ công nghệ không phải là vấn đề, vấn đề là cảm giác thế nào? Nếu sử dụng số ngày có thể làm cho phần mềm sống, sống, giống như một người đàn ông có số sinh nhật. Mỗi năm chúng ta đều lớn lên, Giống như phần mềm đang tiếp tục phát triển.

Số tòa nhà trông giống như máy móc, máy móc, không còn sống, không còn sống.