مفهوم. هذا تقريبًا كما توقعت. في الواقع، في هذه الحالة، سيكون دعم الأدوات مفيدًا على الأقل على المدى المتوسط.
الطريقة التي أتصور بها الأمر هي: أنت على قناة إصدار معينة (الأحدث، الإصدار، ESR)، وعادةً ما تنتقل بسرعة نسبية إلى الإصدار التالي، لذا فإن تلقي رسالة و/أو إشعار عند توفر الإصدار الجديد ووجود أمر واحد للتبديل إليه سيكون رائعًا. وفي الحالات التي أجلت فيها اعتماد إصدار جديد، سيكون من الجيد أيضًا التذكير عندما يصبح الإصدار المستخدم حاليًا قديمًا/غير مدعوم. نقاط إضافية إذا كانت الأداة المعنية تسمح لك أيضًا بالتبديل بين قنوات الإصدار بسرعة
لكنني أتفهم إذا لم يكن ذلك أولوية قصوى الآن، وما زلت توصي الأشخاص بالبقاء على الاختبارات التي تم اجتيازها/الأحدث.
أرى. في سياق عملي، يعتبر طرح ميزة للعملاء “سريعًا”
أيضًا، كما ذكرت أعلاه، كانت فكرتي هي أن الانتقال إلى جدول ربع سنوي سيجعل حياتك (وحياة مطوري الإضافات/السمات) أسهل، لأنه سيكون هناك عدد أقل من الفروع قيد الصيانة. لذا إذا لم يكن الأمر كذلك، فأعتقد أن هذا لا معنى له بالنسبة لك حقًا
SemVer بحد ذاته غير مصمم للتطبيقات الكبيرة. أفهم أنه يستهدف بشكل أكبر المكتبات التي تستهلكها البرامج، وبشكل خاص، تم بناء منطق ترقيم الإصدارات حول واجهة برمجة التطبيقات (API) للحزمة.
يمكننا تطبيق semver على واجهات برمجة التطبيقات (APIs) الخاصة بنا، على الرغم من ذلك. إن وجود ضمانات أقوى حول واجهات برمجة التطبيقات التي يكشف عنها Discourse هو بالتأكيد محادثة جديرة بالاهتمام، ولكن أعتقد أنها منفصلة عن هذه المحادثة.
الآن، أفهم أنك لم تقل أننا يجب أن نكون متوافقين مع SemVer - لقد قلت فقط أننا يجب أن نلتزم باستخدام أرقام متوافقة مع نظام الترقيم المحدد بواسطة SemVer.
يجب أن يأخذ رقم الإصدار العادي الشكل X.Y.Z حيث X و Y و Z هي أعداد صحيحة غير سالبة، ويجب ألا تحتوي على أصفار بادئة. X هو الإصدار الرئيسي، Y هو الإصدار الفرعي، و Z هو إصدار التصحيح. يجب زيادة كل عنصر عدديًا. على سبيل المثال: 1.9.0 → 1.10.0 → 1.11.0.
أعتقد أن اقتراح “الأصفار البادئة” هو الشيء الوحيد الذي سنخالفه إذا سلكنا هذا الطريق.
بخلاف ذلك، أعتقد أن أي مكتبة SemVer ستظل قادرة على تحليل أرقام الإصدارات التي نقترحها وترتيبها بشكل صحيح.
كل هذا جانبًا، هل يمكنك مشاركة المزيد حول لماذا تعتقد أن الامتثال لنظام ترقيم SemVer له قيمة؟
يقول OP أنك لا تستخدم الأصفار البادئة، إذا فهمت بشكل صحيح.
أعتقد أيضًا أن سببًا مقنعًا لاستخدام الأصفار البادئة (الفرز حسب الإصدارات) قد تم اقتراحه. هل الأصفار البادئة هي الخطة الحالية؟ (ما زلت أحب الإصدارات الشهرية بدلاً من الإصدارات التسلسلية).
تكمن فائدة SemVer في أن رقم الإصدار يجب أن ينقل بعض المعلومات المفيدة. المعلومات الوحيدة التي ينقلها مخططك المقترح هي دوران الأرض حول الشمس. هذه المعلومات ليست مفيدة جدًا لمستهلك البرنامج.
إذا كنت أرغب لسبب ما في معرفة تاريخ الإصدار، فسأبحث عن الإصدار وسأحصل على التاريخ الكامل.
ليس حقًا. الهدف هو توصيل طبيعة الإصدار للمستخدم.
إذا كان الإصدار عبارة عن زيادة في إصدار التصحيح، فهذا يعني أن مجموعة التغييرات لا تحتوي على أي شيء من المتوقع أن يؤثر على سير عمل مستخدمي البرنامج.
إذا كان الإصدار عبارة عن زيادة في إصدار ثانوي، فهذا يعني أن مجموعة التغييرات تتضمن إضافة مكونات جديدة تواجه المستخدم، ولكن لا شيء من شأنه أن يكسر سير العمل الحالي لمستخدمي البرنامج.
إذا كان الإصدار عبارة عن زيادة في إصدار رئيسي، فهذا يعني أن مجموعة التغييرات تتضمن تغييرات قد تكسر سير العمل الحالي لمستخدمي البرنامج.
تحديد أي من مكونات الإصدار يجب زيادته يكون أكثر وضوحًا في منتج برمجي يحتوي على واجهة مستخدم واحدة، ولكن المبادئ تظل كما هي حتى بالنسبة لمنتج برمجي مثل Discourse حيث توجد مجموعة متنوعة من مستويات الواجهات وأنواع المستهلكين (على سبيل المثال، مطورو الإضافات، مستهلكو واجهة برمجة التطبيقات، موظفو المنتدى، المستخدمون النهائيون).
حتى لو كان اختيار المكون الذي يجب زيادته أكثر ذاتية في هذا المشروع البرمجي، فإنه لا يزال يؤدي إلى أن يكون لرقم الإصدار معنى بدلاً من مجرد كونه رقمًا عشوائيًا، كما هو الحال مع اقتراحك.
على عكس semver، فإن مخطط ترقيم الإصدار المقترح يوضح على الفور ما إذا كان الإصدار لا يزال مدعومًا (مثل Ubuntu). نظرًا لأن هذا يعتمد أيضًا على دوران الأرض حول الشمس، فإن هذا منطقي بالفعل.
هذا موجه بوضوح نحو الحزم والمكتبات. أي إصدار من Discourse يتضمن تغييرات قد تؤدي إلى تعطيل سير العمل الحالي للمستخدمين للبرنامج. لقد رأيت حتى تصحيحات الأمان تفعل ذلك. Semver غير قابل للاستخدام للتطبيقات المعقدة.
فقط للتأكيد على نقطة قد تضيع، أعتقد أن Discourse يقوم بعمل رائع هنا. أحد التحسينات سيكون على الأقل تسليط الضوء على الموضوعات التي كتبت عنها بالفعل والتي تصف التغييرات والتعطل المحتمل ضمن دورة الترقية هذه. على سبيل المثال، مع إصدار 3.5، اضطررت إلى فتح ملاحظات الإصدار، والنقر للوصول إلى المدونة، ثم النقر بالصدفة على الرابط المتعلق بتجميع المكونات الإضافية مع Discourse الأساسي لالتقاط تلك التفاصيل التي قد تؤثر على الترقيات إذا تركت تلك المكونات الإضافية ضمن ملف التكوين الخاص بي.
سيكون من الرائع سحب هذه الأنواع من الملاحظات إلى صفحة/موضوع لإصدارات ESR، حتى لو كانت مجرد مجموعة من الروابط إلى الموضوعات الموجودة التي يجب مراجعتها قبل إجراء ترقية ESR.
قد يكون هذا خارج نطاق هذا الموضوع - ملاحظاتي على تغيير الإصدار هي أنني أرحب به وأقدر الشفافية هنا. أعتقد أن هذا سيكون تحسينًا رائعًا من شأنه تبسيط الأمور مع منحنا المزيد من الخيارات للاستضافة الذاتية.
تتم دراسة الأصفار البادئة وما إذا كان يجب السعي للمزامنة مع الأشهر بشكل أكثر وضوحًا. سيشارك @david تحديثًا بمجرد أن تتخذ المجموعة التي تعمل على هذا القرار.
هذه ليست المعلومات المهمة لمسؤول المنتدى الذي يقوم بتقييم إصدار جديد.
لا، حقًا. أنت تفوت النقطة الفعلية من SemVer برفض فهم أن “واجهة برمجة التطبيقات” (API) تعني في الواقع الواجهة فقط. لا يوجد سبب على الإطلاق لعدم استخدام روح SemVer في ترقيم أي نوع من البرامج.
لا يهم حقًا إذا كانت مكتبة أو تطبيقًا أكبر. تعمل مخططات الإصدارات الدلالية بشكل جيد جدًا للتطبيقات الكبيرة. يمكن استخدامها حتى لمجموعة من التطبيقات المجمعة في منصة، ولكن هنا يصبح الأمر صعبًا للغاية.
السؤال الرئيسي هو ما إذا كنت ستسلك طريق الإهمال المدعوم في إصدار واحد وإزالته فقط في الإصدار الرئيسي التالي. يمكن أن يتطلب وجود وظائف مهملة ولكن مدعومة جهدًا كبيرًا. عندما تقوم بإجراء تغييرات على نموذج البيانات المستمر الخاص بك، غالبًا ما يصبح الإهمال مستحيلًا. إذا حدث ذلك، فلا يمكنك حتى إجراء إصدار ثانوي بوظائف مهملة، وتقفز فورًا إلى إصدار رئيسي تالٍ. هذا هو الجزء الذي تواجه فيه التطبيقات الكبيرة عادةً مشاكل. تنتقل من 3.0.0 إلى 3.0.1 إلى 4.0.0 لأنك لا تستطيع توفير التوافق مع الإصدارات السابقة. إذا كان لديك تغييرات متكررة تكسر التوافق، فإن الالتزام بـ semver يضيف قيمة قليلة.
مع ذلك. أفضل بكثير هذا البناء لأنه يتواصل بوضوح أكبر مع المطورين أنه ستكون هناك تغييرات تكسر التوافق. مخطط YYYY.N لا يخبرني شيئًا كمطور، ولا شيئًا كمسؤول.
إذًا، السؤال هو، ماذا تريد أن تتواصل به مع الإصدار؟ إذا كنت تريد إجراء 6 إصدارات ميزات (قد تكون أو لا تكون متوافقة مع الإصدارات السابقة)، وكل إصدار سادس سيتم دعمه لفترة أطول مع التصحيحات؛ ولا تريد إصدار أرقام الإصدارات التصحيحية. عندها يكون X.Y مخططًا مناسبًا حيث Y=0 هو الإصدار المدعوم لفترة أطول. سيكون X مجرد رقم. المشكلة هي عندما يكون X هو السنة، فإن Y يرتبط بسرعة بالشهر. لذا، هل سيتم إصدار الإصدارات الأحدث المدعومة لفترة أطول في يناير؟ يجب أن أبحث دائمًا عن إصدار Ubuntu الذي هو LTS، وهذا يزعجني.
إذًا، ماذا لو استمر Discourse ببساطة مع الإصدار الرئيسي الحالي. الإصدار المدعوم لفترة أطول هو 4.0؛ ثم نحصل على 4.1 إلى 4.5 كإصدارات ميزات؛ يليه 5.0 وهو أحدث إصدار مدعوم لفترة أطول.
عندها لن يكون لديك هذا الموقف المحرج حيث يتأخر إصدار بسبب مشكلة رئيسية.
يمكنك اختياريًا إضافة رقم “تصحيح” إذا كنت تخطط لإصدار تصحيحات صراحةً (بدلاً من وجود إصدارات تصحيحية متجددة). “ولكن بعد ذلك لديك x.y.z وهو semver”. حسنًا، لا، يبدو مثل semver، ولكنه ليس كذلك. كل إصدار “ثانوي” جديد يمكن أن يكسر التوافق. لذا أقترح فقط الالتزام بمخطط X.Y كرقم إصدار مع Y=0 → LTS.
بصرف النظر عن سلسلة الإصدارات. أنا حقًا أحب خطة الإصدار الجديدة.
هذا النقاش لا يبدو جيدًا. أرى قرارًا من فريق التطوير بتبني نظام إصدار جديد منطقي بالنسبة لهم، وآخرين يبدو أنهم فجأة يعتبرون أن إصدار Discourse كان يتبع الإصدار الدلالي… وهو لم يكن كذلك. لقد كان دائمًا إصدارًا متدفقًا، على الأقل منذ 1.0، أو؟
لكن الحجج من جميع جوانب النقاش تبدو معيبة:
“معيار الصناعة”: يستخدم لينكس الأرقام الزوجية للإصدارات المستقرة والأرقام الفردية للتطوير.
“الأرض تدور حول الشمس”: حسنًا، إذا أسلمت، ستواجه مشكلة لأنك ستتخلى عن الإصدارات ولن تتوافق مع دوران الشمس، بل مع دورات القمر. هنا، تفهم الآن أنه باختيار مخطط إصدار YYYY.Y.Z بدلاً من X.Y.Z، فرضت ثقافة مهيمنة.
الإصدارات الثانوية لا تزال غير واضحة: تذكر “بافتراض وتيرة شهرية”، ولكن يمكن أن تكون أيضًا 3 أسابيع أو 7، اعتمادًا على الوظيفة، وفي هذه الحالة يكون عد Y من 0 منطقيًا، أو هل تهدف بالفعل إلى الإصدار شهريًا، وفي هذه الحالة يكون عد M من 1 أكثر منطقية؟
التغيير الرئيسي الذي أراه هو أنه من خلال اعتماد وتيرة شهرية، يحدد فريق Discourse التوقعات ويتحرك بعيدًا عن أهداف الإصدار، ويتبنى الإصدارات المنتظمة بدلاً من ذلك.
LTS لمدة 8 أشهر لا تبدو “طويلة” حقًا. NodeJS يتحرك بسرعة كبيرة، لكنهم يحتفظون بدعم LTS لأكثر من 30 شهرًا وعدد قليل من الإصدارات الحالية في وقت واحد، بينما تحتفظ Ubuntu بـ LTS لسنوات. على الرغم من أنني أفهم أن Discourse ليس لغة ولا نظام تشغيل، إلا أنه يبدو أنه يعلن أن الوظائف الجديدة ستصدر بوتيرة سريعة جدًا، مما يثير قضية أخرى في ذهني: نظرًا لأنه يتم تقديم إعدادات إدارية جديدة من وقت لآخر، فسنصل قريبًا إلى جحيم ووردبريس بخيارات لا نهائية وتعقيد لا يمكن فهمه لإدارة الموقع، المعروف باسم البرامج غير المرغوب فيها: يصبح من المهم حينئذ توضيح كيفية الانتقال من الإصدارات الحالية بأهداف إلى الإصدارات المنتظمة، وكيف تختار الأهداف التي يجب إسقاطها (أو تأجيلها) لإصدار ما، وما إلى ذلك (والتي قد تكون موثقة بالفعل، لكنني فاتني ذلك.)
هل تتكرم بمشاركة منطقك بين وتيرة التطوير / الإصدار، وما الذي تفكر فيه لتجنب غرق المسؤولين تحت الكثير من الإعدادات ومنحنى تعلم مرتفع؟
قبل الإجابة على أسئلتك الأخرى، أود أولاً توضيح أن وتيرة الإصدار المخطط لها لا تتغير مع هذا الاقتراح.
على مدار السنوات الثلاث الماضية، كنا نصدر إصدارات “مستقرة” تقريبًا كل 6 أشهر، مستهدفين هذه الإصدارات لنهاية شهري يناير ويوليو من كل عام، مع بعض التأخير هنا وهناك:
في هذا الاقتراح الجديد، نعتزم الحفاظ على نفس الوتيرة التي اتبعناها، مع كون التغييرات الرئيسية هي:
ما نسميه الآن إصدارات “مستقرة”، سنطلق عليه اسم “إصدارات الدعم الممتد”
اخترنا هذا الاسم و ليس “دعم طويل الأمد”، لأننا نتفق على أنه “ممتد” مقارنة بإصداراتنا المدعومة الأخرى، ولكنه ليس بالضرورة “طويل الأمد”. هذا الاقتراح لا يتضمن إضافة إصدار دعم طويل الأمد.
حاليًا، ينتهي دعم إصدار مستقر واحد فورًا عند إصدار الإصدار التالي. مع هذا الاقتراح الجديد، يتداخل الدعم لمدة شهرين تقريبًا، حتى يكون لدى الأشخاص وقت للترقية مع تلقي التصحيحات الأمنية.
ما نسميه الآن إصدارات “تجريبية”، سنطلق عليه اسم “إصدارات”
نحن حاليًا لا ندعم الإصدارات التجريبية على الإطلاق بعد تاريخ إصدارها. إنها مجرد نقاط تفتيش في الطريق تأتي مع إشعار بالتقدم السريع، حيث غالبًا ما تتضمن أيضًا إصلاحات أمنية.
مع هذا الاقتراح، نعتزم دعم الإصدارات لمدة شهرين تقريبًا، حتى يتمكن الأشخاص من تحديد وقت الترقية، مع الاستمرار في تلقي التصحيحات الأمنية.
مع أخذ ذلك في الاعتبار، هل تشعر أن أسئلتك الأخرى حول وجود الكثير من الإعدادات لا تزال مرتبطة بهذا الاقتراح؟ أم أنها مخاوف مستقلة يفضل مناقشتها في موضوع منفصل؟
ليس هذا بالتحديد، لكننا استثمرنا قدرًا لا بأس به في تحسين واجهة المستخدم الإدارية على مدار العام الماضي. إذا كنت ترغب في التعمق في هذه الأمور أكثر، هل يمكنك بدء موضوع جديد وطرح بعض المشكلات و/أو الأفكار التي ترغب في مناقشتها بشكل أكبر؟
هذا تغيير رائع (أحب بشكل خاص دورات الدعم الموسعة المتداخلة)
ملاحظات:
أود أن أرى رسم بياني لدورة الحياة هذا في صفحة مركزية حتى أتمكن من التحقق منه بسهولة، ويفضل أن يكون مع جدول لنهاية العمر المتوقع (EOL) حتى أتمكن من معرفة ما هو مدعوم وما هو غير مدعوم في أي وقت وتخطيط ما يتناسب معه (على الأقل لدورات الدعم الموسعة).
تبديل المسارات:
سيكون هذا رائعًا - ولكن حتى مجرد القدرة على اختيار العلامة (tag) أثناء الإعداد سيكون أمرًا كبيرًا. أو حتى مجرد تضمين الخطوات اليدوية في وثائق الإعداد. إذا أراد شخص ما البدء على المسار المستقر/دورة الدعم الموسعة، فليس من الواضح تمامًا كيف يمكن القيام بذلك الآن لمسؤول جديد. (أعتقد أن الإجابة هي تمرير --skip-rebuild إلى ./launcher، ثم تعديل الإصدار، ثم إجراء إعادة البناء للمرة الأولى، ولكني لست متأكدًا.) نظرًا لأن الإعداد بخلاف ذلك يبدأ فورًا في جلب وتشغيل أحدث إصدار، ثم العودة للخلف يمثل مشكلة.
(مثال على الصعوبة لمسؤول جديد: حاليًا، نتيجة البحث رقم 1 عن “تثبيت ديسكورس المستقر” توجه إلى هذا الموضوع، والذي يرتبط بموضوع آخر يشرح كيفية الترقية إلى المسار المستقر، ولكن ليس كيفية تثبيت المسار المستقر من البداية.)
