C-toxcore: مخطط إصدارات Toxcore

تم إنشاؤها على ٢٣ سبتمبر ٢٠١٦ · 3تعليقات · مصدر: TokTok/c-toxcore

اقتراح

تعمل على افتراض أن توكسكور سوف تتبع الإصدار الدلالي. أقترح أن نتعامل مع أسلوب uTox الخاص بـ sem-ver.

سيكون هناك نسختان من "المسارات" المتاحة. الأول موجود ~ فقط في الكود ، ولن يتعرض لـ git. أما الإصدار الثاني فسيتم طرحه للجمهور ، وتم وضع علامة عليه في git ، وسيكون بمثابة إصدارات "مدعومة".

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

التدفق الفعلي والعلامات التي أقترح اتباعها. (وسيتم تحديثه من التعليقات المقبولة الواردة في هذا الموضوع)

مثال:

git tag v0.0.0 e6af3a7825e8307a501bc7c3e7b1ff323f081870

تم إجراء التغييرات على واجهة برمجة تطبيقات Toxcore (تم بالفعل) ، يجب أن يكون الإصدار المحدد في الكود v0.1.0 لكن هذا الإصدار لن يتعرض لـ (تم وضع علامة في) git.

بعد الانتهاء من تحديث ToxAV عديم الحالة. سيكون الإصدار الموجود في الكود هو v0.2.0 ، مع إضافة git tag v0.2.0 (قد يتم دفع هذا الالتزام اختياريًا إلى فرع جديد stable )

سيؤدي الالتزام التالي بـ master إلى تغيير الإصدار إلى v0.2.1 وسيتم دمج أي / جميع الالتزامات في هذا الفرع. **

بمجرد أن يصبح الإصدار الجديد جاهزًا للدفع إلى الاستقرار ، سيتم زيادة الإصدار الموجود في الكود إلى v0.2.2 (اختياريًا v0.3.0 ) بـ git tag v0.2.2 . سيتم دفع هذا الفرع إلى stable . **

الالتزام التالي بـ master سيكون v0.2.3 ولن تكون هناك علامة git لهذا الإصدار.

مناقشة

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

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

أخيرًا ، يمكن للمطورين تمكين وضع التصحيح افتراضيًا ، إذا اكتشفوا أنهم يستخدمون بناء تطوير Toxcore. ( toxcore_version_patch() % 2 )

مصدر

GrayHatter

👎2

التعليق الأكثر فائدة

أقترح أن نتعامل مع أسلوب uTox الخاص بـ sem-ver.

لا ، من فضلك لا تقدم حماقة واستخدام semver . لا توجد أنماط .

v0.0.1 - لا توجد واجهة برمجة تطبيقات مستقرة ، يمكن لأي شيء غير واجهة برمجة التطبيقات أن يتعطل في أي لحظة
v0.1.0 - لديك واجهة برمجة تطبيقات مستقرة
v0.1.1 - API غير معطل ، بعض الإصلاحات / التحسينات / التغييرات الداخلية
v0.2.0 - كسر في واجهة برمجة التطبيقات ، تغييرات أخرى

بكل بساطة. لا يقفز مجنون 2 الإصدار.

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

ما يبدو أنك تريد القيام به ، هو اتباع مثال GTK / gnome فيما يتعلق بالإصدار - وهو أمر متفق عليه على نطاق واسع على أنه متخلف في عالم التعبئة والتغليف. قد ترغب في التفكير في ذلك.

قد ترغب في معرفة ماهية semver ، نظرًا لأن مخطط الإصدار الذي تقترحه _ ليس semver_.

إذا لم تطلق شيئًا كعلامة في git ، فلن يتم تعبئته. فترة.
إذا تم وضع علامة عليه ، فهو إصدار ويتم تعبئته.

في ملحوظة جانبية؛ لا تحتاج إلى فرع stable - استخدم git tag s.