لماذا يتم تعريف System.version in .NET باسم major.minor.build.revision؟

Question

لماذا يتم تعريف System.version in .NET باسم major.minor.build.revision؟ يبدو أن الجميع تقريبًا (بما في ذلك أنا) يتفقون على أن المراجعة تنتمي إلى المركز الثالث ، و "بناء" أو أي شيء ترغب في تسميته ينتمي إليه أخيرًا.

هل تستخدم Microsoft الأرقام بهذه الطريقة العشوائية ، على سبيل المثال 3.5.3858.2 ، أم أن الأسماء نفسها تعود إلى الوراء؟ وض متخلفون؟

Answer 1

أعتقد أن الارتباك يأتي ما يعتبره أكثر "مراجعة" و ماذا تفعل Microsoft:

• يبني: يمثل الاختلاف في رقم البناء إعادة تجميع لنفس المصدر. سيكون هذا مناسبًا بسبب تغييرات المعالج أو النظام الأساسي أو المترجم.

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

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

Answer 2

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

إصدار التجميع ، عندما يتعلق الأمر به ، هو Major.minor. من المذكورة أعلاه حلقة الوصل, تقول Microsoft ، "الإصدارات اللاحقة من التجميع التي تختلف فقط حسب أرقام البناء أو المراجعة تعتبر تحديثات الإصلاح الساخنة للمسبقة إصدار[تركيزي

ال يبني يمثل إعادة تجميع نفس المصدر. ال مراجعة يمثل تغيير رمز ، ولكنه يمكن تبادله تمامًا مع المراجعات الأخرى لنفس الإصدار [major.minor]. ولكن لا الأسبقية على الآخر.

لذا ، باختصار ، لا تفكر في الأمر على النحو التالي:

+ Major
|
+-+ Minor
  |
  +-+ Build
    |
    +-+ Revision

ولكن بدلا من ذلك:

+ Major
|
+-+ Minor
  |
  +-+ Build
  |
  +-+ Revision

Answer 3

هل تستخدم Microsoft الأرقام بهذه الطريقة العشوائية ، على سبيل المثال 3.5.3858.2

إذا سمحت له افتراضيًا ، على سبيل المثال ، عن طريق تحديد [assembly: AssemblyVersion("1.1.*")], ، ثم الزيادات في الرقم الثالث كل يوم ، والرقم الرابع هو عدد الثواني منذ منتصف الليل ، مقسومًا على اثنين (إلى الغموض إذا كان هناك أكثر من واحد يبني في يوم واحد).

يبدو أن الجميع تقريبًا (بما في ذلك أنا) يتفقون على أن المراجعة تنتمي إلى المركز الثالث ، و "بناء" أو أي شيء ترغب في تسميته ينتمي إليه أخيرًا.

يبدو أن Microsoft تستخدم "Build" كمرادف لـ "Day": ربما يرتبط هذا بفكرة "التصميمات اليومية" ؛ و "المراجعة" هي إذن نسخة أخرى من البناء (اليومي).

Answer 4

الإجابة المتأخرة ، لكنني أشعر أن الإجابات الأخرى يمكن توسيعها قليلاً.

مصطلحات "البناء" و "المراجعة" هي مجرد مصطلحات Microsoft. لا يهتم فئة System.Version بأي طريقة لكي تتمكن من تعيينها.

أما بالنسبة لتبديل ترتيب الأجزاء لمطابقة المصطلحات الخاصة بك ، أود أن أقول أنه يجب عليك تجاهل الكلمات تمامًا وبدلاً من ذلك فكر في ما هو النظام حقًا يعرّف:

• تنسيق سلسلة يمكنه تحليله وتوليده:

  major.minor[.build[.revision]]
  

  هذا يعني أنه إذا كنت معتادًا على امتلاك نسخة من تنسيق XYZW ، فيجب عليك إنشاء إنشاء فئة الإصدار بهذه الطريقة:

  new Version(x, y, z, w)
  

  لن يتطابق أي ترتيب معلمة آخر مع Parse () و ToString (). إذا قمت بتبديل Z و W ، فإن ToString () ستخرج XYWZ والتي ستكون مربكة للجميع إذا كنت تتوقع xyzw

• أ مقارنة الإصدار وترتيب الفرز, ، حيث يتم فرز الإصدارات أولاً بواسطة Major ، ثم بواسطة Minor ، ثم بناء ، ثم المراجعة ، كما يتوقع معظمنا. وهذا هو ، 1.2.5 في وقت متأخر من 1.2.3.7.

  لذلك إذا قمت بتصميم سلسلة الإصدار الخاصة بك كـ 1.2.6.4 وتريد أن تعتبر أحدث من 1.2.5.8 ، فلا تقوم بتبديل ترتيب الأجزاء في مُنشئ الإصدار.

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