الحصول على أرقام إصدارات البرنامج بشكل صحيح.الإصدار 1.0.0.1 [مغلق]

Question

أقوم بتوزيع البرامج عبر الإنترنت، وأتساءل دائمًا عما إذا كانت هناك طريقة مناسبة لتحديد أرقام الإصدارات بشكل أفضل.

لنفترض A.B.C.D في الإجابات.متى تزيد كل مكون من المكونات؟

هل تستخدم أي حيل أخرى لرقم الإصدار مثل D mod 2 == 1 مما يعني أنه إصدار داخلي فقط؟

هل لديك إصدارات بيتا بأرقام الإصدارات الخاصة بها، أو هل لديك إصدارات بيتا لكل رقم إصدار؟

Answer 1

لقد بدأت أحب اتفاقية Year.Release[.Build] التي تستخدمها بعض التطبيقات (مثل.بالقوة) الاستخدام.في الأساس، يشير فقط إلى العام الذي تم إصداره فيه، والتسلسل خلال تلك السنة.لذلك سيكون 2008.1 هو الإصدار الأول، وإذا قمت بإصدار إصدار آخر بعد أشهر أو ثلاثة، فسوف ينتقل إلى 2008.2.

تتمثل ميزة هذا المخطط في عدم وجود "حجم" ضمني للإصدار، حيث تدخل في جدالات حول ما إذا كانت الميزة كبيرة بما يكفي لتبرير زيادة كبيرة في الإصدار أم لا.

هناك ميزة إضافية اختيارية تتمثل في وضع علامة على رقم الإصدار، ولكن هذا يميل إلى أن يكون للأغراض الداخلية فقط (على سبيل المثال.تمت إضافته إلى EXE/DLL حتى تتمكن من فحص الملف والتأكد من وجود البنية الصحيحة).

Answer 2

في رأيي، يمكن جعل أي مخطط لرقم الإصدار تقريبًا يعمل بشكل أكثر أو أقل عقلانية.يستخدم النظام الذي أعمل عليه أرقام الإصدارات مثل 11.50.UC3، حيث يشير حرف U إلى Unix 32 بت، وC3 هو رقم مراجعة ثانوية (حزمة الإصلاح)؛يتم استخدام أحرف أخرى لأنواع المنصات الأخرى.(لا أوصي بهذا المخطط، لكنه يعمل.)

هناك بعض القواعد الذهبية التي لم يتم ذكرها حتى الآن، ولكنها ضمنية فيما ناقشه الناس.

• لا تقم بإصدار نفس الإصدار مرتين - بمجرد إصدار الإصدار 1.0.0 لأي شخص، لا يمكن إعادة إصداره أبدًا.
• يجب أن تزيد أرقام الإصدار بشكل رتيب.أي أن التعليمات البرمجية الموجودة في الإصدار 1.0.1 أو 1.1.0 أو 2.0.0 يجب أن تكون دائمًا أحدث من الإصدار 1.0.0 أو 1.0.9 أو 1.4.3 (على التوالي).

الآن، من الناحية العملية، يتعين على الأشخاص إصدار إصلاحات للإصدارات الأقدم أثناء توفر الإصدارات الأحدث - راجع مجلس التعاون الخليجي، على سبيل المثال:

• تم إصدار دول مجلس التعاون الخليجي 3.4.6 بعد 4.0.0 و4.1.0 (وAFAICR 4.2.0)، لكنه يواصل وظائف دول مجلس التعاون الخليجي 3.4.x بدلاً من إضافة الميزات الإضافية المضافة إلى دول مجلس التعاون الخليجي 4.x.

لذلك، عليك إنشاء نظام ترقيم الإصدارات الخاص بك بعناية.

نقطة أخرى أؤمن بها بشدة:

• لا يرتبط رقم إصدار الإصدار بترقيم إصدار نظام CM (VCS)، باستثناء البرامج التافهة.أي برنامج جدي يحتوي على أكثر من ملف مصدر رئيسي سيكون له رقم إصدار لا علاقة له بإصدار أي ملف منفرد.

باستخدام SVN، يمكنك استخدام رقم إصدار SVN - ولكن من المحتمل ألا تستخدمه لأنه يتغير بشكل غير متوقع.

بالنسبة للأشياء التي أعمل بها، فإن رقم الإصدار هو قرار سياسي بحت.

وبالمناسبة، أعرف برامج مرت بإصدارات من الإصدار 1.00 إلى الإصدار 9.53، ولكن تغير ذلك بعد ذلك إلى الإصدار 2.80.لقد كان ذلك خطأً فادحًا، فرضه التسويق.من المؤكد أن الإصدار 4.x من البرنامج قد عفا عليه الزمن، لذلك لم يحدث ارتباك على الفور، ولكن الإصدار 5.x من البرنامج لا يزال قيد الاستخدام وبيعه، وقد وصلت المراجعات بالفعل إلى 3.50.أنا قلق جدًا بشأن ما سيفعله الكود الخاص بي الذي يجب أن يعمل مع كل من الإصدار 5.x (النمط القديم) و5.x (النمط الجديد) عند حدوث التعارض الحتمي.أعتقد أنني يجب أن آمل أن يجتهدوا في التغيير إلى 5.x حتى يموت الإصدار 5.x القديم بالفعل - لكنني لست متفائلاً.أستخدم أيضًا رقم إصدار مصطنعًا، مثل 9.60، لتمثيل الكود 3.50، حتى أتمكن من التصرف بعقلانية if VERSION > 900 الاختبار، بدلاً من الاضطرار إلى القيام بما يلي: if (VERSION >= 900 || (VERSION >= 280 && VERSION < 400), ، حيث أمثل الإصدار 9.00 في 900.ثم هناك التغيير المهم الذي تم إدخاله في الإصدار 3.00.xC3 - فشل مخططي في اكتشاف التغييرات على مستوى الإصدار الثانوي...تذمر...تذمر...

ملحوظة::يقدم إريك ريموند كيفية ممارسة إصدار البرامج بما في ذلك القسم (المرتبط) الخاص بتسمية (ترقيم) الإصدارات.

Answer 3

عادةً ما أستخدم D كأحد عداد البناء (الزيادة التلقائية بواسطة برنامج التحويل البرمجي) I زيادة C في كل مرة يتم فيها إصدار البناء إلى "Public" (وليس إصدار كل بناء) A و B يتم استخدامهما كرقم رئيسي/ثانوي وتغييره يدويًا.

Answer 4

أعتقد أن هناك طريقتين للإجابة على هذا السؤال، وهما ليسا متكاملين تمامًا.

1. اِصطِلاحِيّ:زيادة الإصدارات على أساس المهام الفنية.مثال:D هو رقم الإصدار، وC هو التكرار، وB هو إصدار ثانوي، وA هو إصدار رئيسي.يعد تحديد الإصدارات الثانوية والرئيسية أمرًا شخصيًا حقًا، ولكن يمكن أن يكون مرتبطًا بأشياء مثل التغييرات في البنية الأساسية.
2. تسويق:قم بزيادة الإصدارات بناءً على عدد الميزات "الجديدة" أو "المفيدة" التي يتم توفيرها لعملائك.يمكنك أيضًا ربط أرقام الإصدارات بسياسة التحديث...تتطلب التغييرات التي يتم إجراؤها على A من المستخدم شراء ترخيص ترقية، بينما لا تتطلب التغييرات الأخرى ذلك.

أعتقد أن خلاصة القول هي العثور على نموذج يناسبك ويناسب عملائك.لقد رأيت بعض الحالات التي تكون فيها الإصدارات حتى إصدارات عامة، والإصدارات الفردية تعتبر إصدارات تجريبية أو إصدارات مطورة.لقد رأيت بعض المنتجات التي تتجاهل C وD معًا.

ثم هناك المثال من Micrsoft، حيث التفسير العقلاني الوحيد لأرقام إصدارات .Net Framework هو أن التسويق كان متورطًا.

Answer 5

سياستنا:

• أ - تغييرات كبيرة (> 25 ٪) أو الإضافات في الوظيفة أو الواجهة.
• ب - التغييرات الصغيرة أو الإضافات في الوظيفة أو الواجهة.
• ج - التغييرات البسيطة التي تكسر الواجهة.
• D - إصلاحات إلى بناء لا يغير الواجهة.

Answer 6

يميل الناس إلى جعل هذا الأمر أصعب بكثير مما يجب أن يكون عليه بالفعل.إذا كان منتجك يحتوي على فرع واحد فقط طويل الأمد، فما عليك سوى تسمية الإصدارات المتعاقبة حسب رقم الإصدار الخاص بها.إذا كان لديك نوع من "إصلاحات الأخطاء الطفيفة مجانية، ولكن عليك الدفع مقابل الإصدارات الجديدة الرئيسية"، فاستخدم 1.0، 1.1...1.ن، 2.0، 2.1...إلخ.

إذا لم تتمكن على الفور من معرفة ما هي A وB وC وD في مثالك، فمن الواضح أنك لا تحتاج إليها.

Answer 7

الاستخدام الوحيد الذي قمت به على الإطلاق لرقم الإصدار كان حتى يتمكن العميل من إخباري أنه يستخدم الإصدار 2.5.1.0 أو أي شيء آخر.

تم تصميم قاعدتي الوحيدة لتقليل الأخطاء في الإبلاغ عن هذا الرقم: يجب أن تتكون جميع الأرقام الأربعة من رقم واحد فقط.

1.1.2.3

على ما يرام، ولكن

1.0.1.23

ليس.من المرجح أن يقوم العملاء بالإبلاغ عن كلا الرقمين (لفظيًا، على الأقل) كـ "واحد-واحد-اثنان-ثلاثة".

غالبًا ما تؤدي أرقام الإصدار المتزايدة تلقائيًا إلى أرقام الإصدارات مثل

1.0.1.12537

وهو ما لا يساعد حقًا أيضًا.

Answer 8

يستخدم المخطط الجيد وغير الفني تاريخ الإنشاء بهذا التنسيق فقط:

YYYY.MM.DD.BuildNumber

حيث يكون BuildNumber إما رقمًا مستمرًا (قائمة التغيير) أو يبدأ من جديد عند رقم 1 كل يوم.

أمثلة:2008.03.24.1 أو 2008.03.24.14503

هذا مخصص بشكل أساسي للإصدارات الداخلية، حيث ستشهد الإصدارات العامة الإصدار مطبوعًا على أنه 2008.03 إذا لم تقم بالإصدار أكثر من مرة واحدة في الشهر.يتم وضع علامة على إصدارات الصيانة على أنها 2008.03a 2008.03b وما إلى ذلك.نادرًا ما يجب عليهم تجاوز "c" ولكن إذا حدث ذلك، فهذا مؤشر جيد، فأنت بحاجة إلى إجراءات ضمان الجودة و/أو الاختبار بشكل أفضل.

يجب طباعة حقول الإصدار التي يشاهدها المستخدم بشكل شائع بتنسيق "مارس 2008" المألوف، مع الاحتفاظ بالمعلومات التقنية الإضافية في مربع الحوار "حول" أو ملفات السجل.

أكبر عيب:مجرد تجميع نفس الكود في يوم آخر قد يغير رقم الإصدار.ولكن يمكنك تجنب ذلك عن طريق استخدام قائمة تغيير التحكم في الإصدار كرقم أخير والتحقق من ذلك لتحديد ما إذا كان التاريخ بحاجة إلى التغيير أيضًا.

Answer 9

أنا أستخدم V.R.M على سبيل المثال.2.5.1

تعد تغييرات V (الإصدار) بمثابة إعادة كتابة رئيسية
تعد تغييرات R (المراجعة) ميزات جديدة مهمة أو إصلاحات للأخطاء
تغييرات M (التعديل) هي إصلاحات بسيطة (الأخطاء المطبعية، وما إلى ذلك)

أستخدم أحيانًا رقم التزام SVN في النهاية أيضًا.

Answer 10

الأمر كله شخصي حقًا في نهاية اليوم ويعود ببساطة إلى نفسك/فريقك.

ما عليك سوى إلقاء نظرة على جميع الإجابات بالفعل - كلها مختلفة تمامًا.

شخصيا أستخدم Major.Minor.*.* - حيث يقوم Visual Studio بملء رقم المراجعة/الإصدار تلقائيًا.يستخدم هذا حيث أعمل أيضا.

Answer 11

تم وصف نظام إصدار جيد وسهل الاستخدام تم إنشاؤه في نظام التشغيل Mac OS القديم في هذه المذكرة الفنية لشركة Apple: http://developer.apple.com/technotes/tn/tn1132.html

Answer 12

أنا أحب سنة.شهر.يوم. لذلك، v2009.6.8 سيكون "الإصدار" من هذا المنشور.من المستحيل التكرار (بشكل معقول) ومن الواضح جدًا عندما يكون هناك إصدار أحدث.يمكنك أيضًا إسقاط الكسور العشرية وجعلها v20090608.

Answer 13

في حالة المكتبة، يخبرك رقم الإصدار عن مستوى التوافق بين إصدارين، وبالتالي مدى صعوبة الترقية.

يحتاج إصدار إصلاح الأخطاء إلى الحفاظ على التوافق الثنائي والمصدر والتسلسل.

الإصدارات الثانوية تعني أشياء مختلفة لمشاريع مختلفة، ولكنها عادة لا تحتاج إلى الحفاظ على توافق المصدر.

يمكن لأرقام الإصدارات الرئيسية كسر جميع الأشكال الثلاثة.

لقد كتبت المزيد عن الأساس المنطقي هنا.

Answer 14

في عالم جيثب، أصبح من الشائع اتباع مواصفات Tom Preston-Werner "semver" لأرقام الإصدارات.

من http://semver.org/ :

بالنظر إلى رقم الإصدار MAJOR.MINOR.PATCH، قم بزيادة:

الإصدار الرئيسي عند إجراء تغييرات API غير المتوافقة ، وإصدار بسيط عند إضافة وظائف بطريقة متوافقة مع الوراء ، وإصدار التصحيح عند إجراء إصلاحات أخطاء متوافقة مع الخلف.تتوفر ملصقات إضافية لبيانات التعريف قبل الإصدار والبناء كملحقات لتنسيق major.minor.patch.

Answer 15

للتطوير الداخلي، نستخدم التنسيق التالي.

[Program #] . [Year] . [Month] . [Release # of this app within the month]

على سبيل المثال، إذا كنت سأطلق التطبيق رقم 15 اليوم، وهو التحديث الثالث هذا الشهر، فسيكون الإصدار رقم 15 الخاص بي هو

15.2008.9.3

إنه غير قياسي تمامًا، ولكنه مفيد لنا.

Answer 16

بالنسبة للإصدارات الستة الرئيسية الماضية، استخدمنا M.0.m.b حيث M هو الإصدار الرئيسي، وm هو الإصدار الثانوي، وb هو رقم الإصدار.لذلك تضمنت الإصدارات التي تم إصدارها 6.0.2، 7.0.1، ...، وحتى 11.0.0.لا تسأل لماذا الرقم الثاني هو دائما 0؛لقد سألت عدة مرات ولا أحد يعرف حقا.لم يكن لدينا رقم غير الصفر هناك منذ إصدار 5.5 في عام 1996.