تثبيت إصدار Flutter لكل مشروع باستخدام FVM وتوحيد المحرر وCI، وفصل قيد Dart SDK عن توافق إصدار Flutter والتبعيات.
Flutter وDart إصداران مرتبطان
القيد environment.sdk في pubspec.yaml يخص Dart، ولا يعني أن أي إصدار Flutter داخل أرقام هذا القيد يصلح للمشروع. كل Flutter يأتي بنسخة Dart وتبعيات أدواته، وقد تحتاج plugins حدًا أدنى مختلفًا. اختر إصدار Flutter كاملًا مثبتًا بعد اختبار المشروع، ولا تعرض 2.10 مثالًا جاهزًا لمشروع حديث.
استخدم المسار الذي يديره FVM
الأوامر التي تشغّل Flutter تمر عبر fvm flutter مثل fvm flutter pub get وfvm flutter test. تحقق من إصدار FVM المثبت وطريقة ضبط IDE، ثم سجّل ملف إعداد المشروع المطلوب في Git وفق دليل FVM. لا تنسخ مجلد SDK كاملًا للمستودع، ولا تعالج خطأ Android v1 embedding بتبديل سطر manifest فقط إذا كانت الإضافة القديمة نفسها تحتاج ترحيلًا.
تثبيت إصدار لكل مشروع
FVM يدير نسخ Flutter ويتيح ربط مشروع بإصدار مقصود بدل تعديل SDK العام كل مرة. اختر إصدارًا كاملًا بعد مراجعة قيود Dart والحزم وأدوات Android وXcode المطلوبة، ثم استخدم fvm install وfvm use وفق نسخة الأداة المثبتة. stable اسم قناة يتحرك مع الوقت، لذلك سجّل الإصدار المحلول فعليًا إن أردت بناءً يعاد إنتاجه. لا تجعل نجاح تشغيل مشروع جديد دليلًا أن مشروعًا قديمًا يستطيع الترقية إليه بلا ترحيل.
توحيد الطرفية والمحرر
قد يشير flutter في PATH إلى نسخة عامة بينما fvm flutter يستعمل نسخة المشروع، فيظهر اختلاف غامض بين IDE والطرفية. شغل الأمرين مع –version وقارن ثم اضبط مسار SDK للمحرر حسب دليل FVM. افتح جلسة طرفية أو نافذة محرر جديدة عند الحاجة. استعمل fvm flutter pub get وfvm flutter test في أوامر المشروع، ولا تختصرها إلى fvm pub get إذا لم يكن ذلك أمرًا مدعومًا في نسختك.
ملفات الفريق وCI
شارك إعداد الإصدار الذي يحتاجه الفريق ولا ترفع ملفات SDK الثقيلة أو مسارات رمزية محلية من جهازك إلى المستودع. في CI ثبت الإصدار نفسه أو استخدم آلية FVM الموثقة ثم نفذ التحليل والاختبارات قبل البناء. احتفظ بـpubspec.lock للتطبيق ومعلومات أدوات البناء حتى لا تنسب فرق التبعيات إلى FVM خطأً. اختلاف CocoaPods أو Java أو Xcode قد يفسر فشلًا رغم تطابق Flutter، لذلك توثيق البيئة يمتد لأكثر من رقم واحد.
الترقية والعودة
نفذ ترقية المشروع في فرع يمكن مراجعته، وراجع تغييرات الملفات المولدة والكود القديم والتنبيهات. Android embedding القديم يحتاج ترحيل التطبيق والإضافات التي تعتمد عليه، لا مجرد استبدال android:name دائمًا. جرب بناء نسخة release وتدفقًا مهمًا على كل منصة مطلوبة ثم احتفظ بنتيجة الاختبار قبل اعتماد الإصدار. العودة لإصدار Flutter سابق لا تعيد تلقائيًا تعديلات source أو ملفات lock التي غيرتها؛ احتفظ بها تحت تحكم إصدار حتى يكون الرجوع واضحًا وقابلًا للتحقق.
تنظيف نسخ SDK بحذر
بعد استقرار المشاريع يمكنك مراجعة قائمة إصدارات FVM وحجمها، لكن لا تحذف نسخة يعتمد عليها مشروع لا تفتحه يوميًا. احتفظ بسجل إصدار كل مشروع وبإمكانية تنزيله لاحقًا، وافصل cache أدوات البناء عن نسخ SDK نفسها. تشغيل fvm list يساعد المعاينة، أما إزالة إصدار فهي قرار إدارة بيئة يحتاج معرفة التبعيات، ولا ينبغي أن يحدث ضمن أمر روتيني لتثبيت إصدار جديد.
مراجعة أخيرة للتطبيق
تحقق من إعداد SDK الذي يستعمله المحرر بعد تبديل الإصدار.
مثال الشفرة بعد المراجعة
اقرأ التعليقات ومتطلبات الإعداد قبل النقل إلى مشروعك. أمثلة الواجهات ذات main مستقلة، أما العقود والمقاطع الأصلية وملفات الإعداد فموضح نطاقها داخل المثال.
dart pub global activate fvm
fvm releases
# Choose a full Flutter version compatible with the project, then:
# fvm install <version>
# fvm use <version>
fvm flutter --version
fvm flutter pub get
fvm flutter analyze
fvm flutter testالصور والفيديو التوضيحي
قد تعرض الوسائط إصدارًا أقدم. اعتمد الخطوات النصية المصححة عند اختلاف إعدادات المنصة أو أسماء الواجهات.
مرجع للتنفيذ
راجع التوثيق الخاص بهذا الموضوع وطابق إعداداته مع إصدار أدوات مشروعك. اختبر السلوك المستهدف وحالة الفشل قبل إدماج المثال في تطبيق منشور.
