استراتژی توسعه جوملا

مقدمه

این سند استراتژی، آنچه جامعه کاربران جوملا—از کاربران عادی غیر فنی تا توسعه‌دهندگان فنی سطح بالا—می‌توانند از محصولات تحت پروژه جوملا انتظار داشته باشند را مشخص می‌کند.

تمرکز اصلی این استراتژی بر نحوه مواجهه و مدیریت تغییرات است: چگونه محصولات خود را در چشم‌انداز فناوری که دائما در حال تغییر است، سازگار کرده و آن را توسعه و گسترش می‌دهیم؛ چگونه به کاربران و مشارکت‌کنندگان اطلاع می‌دهیم که از یک نسخه به نسخه بعدی چه تغییراتی انتظار داشته باشند؛ و چگونه مشارکت‌کنندگان را راهنمایی می‌کنیم تا تغییرات آینده‌ای را که جامعه به آن‌ها نیاز دارد، ایجاد کنند.

ذینفعان پروژه ما نیازهای بسیار متفاوتی دارند و باید تعادل مناسبی برقرار شود بین کسانی که تغییر برایشان ناخوشایند است و در طرف مقابل کسانی که با تغییرات مداوم رشد می‌کنند. تغییر برای حفظ ارتباط محصولات با کاربران هدف ضروری است، بنابراین هدف ما این است که این تغییرات را طوری مدیریت کنیم که کمترین مزاحمت و اختلال را ایجاد کنند.

با توجه به اینکه پروژه جوملا مسئول بیش از یک محصول است، این استراتژی به گونه‌ای نوشته شده که تا حد امکان کلی باشد و اجازه دهد محصولات جدید بدون نیاز به بازنویسی‌های گسترده، به مجموعه محصولات ما افزوده شوند.

این استراتژی بر پایه تجربه عملی گسترده بسیاری از افراد در طول سال‌های پس از تأسیس پروژه بنا شده است. دلایل و درس‌های آموخته شده پشت این متن در حد این سند نیست و برای بررسی آن‌ها باید به منابع دیگر مراجعه شود.

این سند یک مرور کلی و نقطه شروع است و به اسناد دیگر ارجاع می‌دهد تا اطلاعات در یک جای مناسب و به‌روز در دسترس باشد، به طوری که اطلاعات معتبر و جدید باقی بماند.

خلاصه اجرایی

این سند طولانی نیست، اما با توجه به اطلاعات موجود در سایر مستندات، محتوای زیادی برای خواندن وجود دارد. با درک این واقعیت، این بخش تلاش می‌کند آنچه لازم است بدانید را خلاصه کند و شما را به بخش‌های مناسب برای اطلاعات بیشتر راهنمایی نماید.

نکات کلیدی این استراتژی عبارتند از:

- طرح شماره‌گذاری نسخه کلید فهم درجه تغییرات یک انتشار است. شماره نسخه سه بخش دارد که با نقطه از هم جدا شده‌اند: [اصلی].[فرعی].[اصلاح]. برای مثال، نسخه ۵.۳.۲ دارای شماره اصلی ۵، فرعی ۳ و اصلاح ۲ است. نسخه‌ای که شماره اصلی را افزایش می‌دهد، انتشار اصلی نامیده می‌شود؛ نسخه‌ای که فقط شماره فرعی را افزایش می‌دهد، انتشار فرعی است؛ و نسخه‌ای که فقط شماره اصلاح را افزایش می‌دهد، انتشار اصلاحی است. برای جزئیات بیشتر به سیاست انتشار مراجعه کنید.

- یک انتشار زمانی «سازگار با نسخه‌های قبلی» گفته می‌شود که سیستم شما پس از بروزرسانی به آن نسخه به درستی کار کند حتی اگر سایر بخش‌های سیستم همزمان بروزرسانی نشده باشند. با این حال، محدودیت‌هایی برای سازگاری با نسخه‌های قبلی وجود دارد که باید برای جزئیات کامل، سیاست سازگاری با نسخه‌های قبلی را مطالعه کنید.

- فقط انتشارهای اصلی ممکن است عمداً سازگاری به نسخه پیشین را بشکنند. انتشارهای فرعی می‌توانند ویژگی‌ها و قابلیت‌های جدید اضافه کنند اما باید با نسخه قبلی سازگار باشند. انتشارهای اصلاحی فقط برای رفع اشکال و مشکلات امنیتی هستند و سازگاری به نسخه پیشین را نمی‌شکنند. البته، رفع مشکل امنیتی ضروری ممکن است در هر نوع انتشار باعث شکستن سازگاری شود.

- نسخه‌ها یا پشتیبانی می‌شوند یا نمی‌شوند. وقتی می‌گوییم یک نسخه پشتیبانی می‌شود، یعنی همه مسائل اصلی و اکثر مسائل فرعی در انتشار بعدی رفع خواهند شد. برای اطلاعات بیشتر به سیاست پشتیبانی مراجعه کنید.

- در هر سری اصلی فقط آخرین نسخه فرعی پشتیبانی می‌شود. با منتشر شدن نسخه فرعی جدید، پشتیبانی نسخه فرعی قبلی پایان می‌یابد.

- یک سری اصلی فقط پس از حداقل دو سال از آخرین نسخه فرعی آن سری می‌تواند به‌عنوان پایان عمر اعلام شده و دیگر پشتیبانی نشود. یعنی هر بار نسخه فرعی جدید منتشر شود، «ساعت پشتیبانی» آن سری ریست می‌شود و به این ترتیب سری اصلی تا زمانی که علاقه به تولید نسخه‌های فرعی وجود دارد، عمر طولانی خواهد داشت. انتشارهای اصلاحی این «ساعت پشتیبانی» را ریست نمی‌کنند.

- همیشه یک مسیر آپدیت پشتیبانی‌شده از یک نسخه به هر نسخه بعدی وجود دارد. با تعریف واضح این مسیر، کاربران اطمینان بیشتری به موفقیت آپدیت خواهند داشت و توسعه‌دهندگان می‌دانند دقیقا کدام مسیرهای آپدیت باید تست شوند. برای جزئیات بیشتر به سیاست آپدیت مراجعه کنید.

- ما امنیت را بسیار جدی می‌گیریم و تیم ویژه‌ای به نام JSST داریم که تمام مشکلات گزارش شده را بررسی و اقدامات لازم برای رفع یا کاهش آن‌ها را انجام می‌دهند. برای اطلاعات بیشتر به سیاست امنیت مراجعه کنید.

- ما از مشارکت‌های فردی، گروهی یا شرکتی استقبال می‌کنیم که محصولات ما را به نفع جامعه بهبود بخشد. برای جزئیات به سیاست مشارکت‌کنندگان مراجعه کنید.

ماموریت

ماموریت ما ارائه یک بستر منعطف برای نشر دیجیتال و همکاری است.

اهداف

- فراهم کردن یک بستر پایدار و قابل‌اعتماد برای کاربران فعلی و آینده‌ی ما.

- در دسترس قرار دادن نوآوری برای کاربران و توسعه‌دهندگان به صورت مدیریت‌شده.

- آسان کردن فرآیند مشارکت توسعه‌دهندگان در ارائه کد و مستندات پروژه در هر زمان.

اصول

جوملا سعی می کند شعار "قدرت از طریق سادگی" را برای تمام پیشرفت های خود دنبال کند. برای این کار، ما پنج اصل اصلی ذاتی استراتژی توسعه جوملا با هدف دستیابی به اهداف خود داریم:

ثبات

برای مأموریت ما بسیار مهم است که شاخه‌های نسخه‌های یک محصول جوملا همیشه پایدار و آماده انتشار در مدت کوتاهی باشند.

• انتشار نرم افزارهای افزایشی و قابل پیش بینی
• ما یک طرح انتشار منتشر شده با تاریخ های مشخص برای انتشار داریم.
• پشتیبانی قوی از سازگاری نسخه پیشین
• سازگاری به نسخه پیشین برای هر پلتفرم نرم افزاری از اولویت بالایی برخوردار است.

سیاست امنیتی صحیح

تیم Security Strike ما همیشه در دسترس است و به موقع به مسائل پاسخ می دهد.

فرآیند توسعه باز

فرآیند توسعه ما به گونه ای طراحی شده است که برای هر کسی که مایل به مشارکت است، باز و در دسترس باشد. ما در تلاش هستیم تا محیطی ایجاد کنیم که در آن افراد برای حل مشکلات با یکدیگر همکاری کنند و ایده های نوآورانه و تازه را در نرم افزاری که تولید می کنیم، زنده کنند.

سیاست مشارکت

سیاست های مشارکت در کد منبع را می توان در مخازن در github یافت.

چرخه انتشار نرم افزار

شرح زیر در مورد چرخه انتشار نرم افزار مربوط به محصول اصلی ما، CMS است. جوملا با نسخه 4.0 به چرخه انتشار به موقع تغییر کرد. این بدان معنی است که هر دو سال یک نسخه اصلی از CMS منتشر می شود. تاریخ انتشار برای اکتبر در یک سال با یک عدد سال فرد برنامه ریزی شده است (به عنوان مثال 2025، 2027، 2029 ...). در عرض دو سال ما هر 6 ماه یک نسخه جزئی را منتشر می کنیم. انتشار پچ معمولاً هر 6 هفته یکبار منتشر می شود.

مراحل چرخه عمر

چرخه عمر انتشار نرم افزار از مراحل و نقاط عطف متمایز تشکیل شده است که بیانگر بلوغ نرم افزار از برنامه ریزی به توسعه تا انتشار و پشتیبانی است. هر نسخه ای از تمام مراحل ممکن عبور نمی کند. برای مثال، انتشار وصله‌ها معمولاً نقاط عطف آلفا و بتا را حذف می‌کنند.

مرحله برنامه ریزی

مرحله برنامه ریزی بیشتر شامل بحث و گفتگو با نرم افزار واقعی کمی یا بدون احتمال در دسترس بودن است. یک ایده برای یک ویژگی جدید ممکن است اولین گام های آزمایشی خود را به سمت پیاده سازی با بحث RFC در github یا انتشار یک درخواست برای نظرات (RFC) بردارد. RFC یک بحث درباره یک ایده و اجرای بالقوه آن با دعوت از جامعه گسترده تر برای مشارکت در بحث، بازخورد و اصلاح ایده است.

در طول مرحله برنامه‌ریزی، ممکن است برخی از کدها یا پیاده‌سازی‌های اثبات مفهوم تولید شوند تا امکان‌پذیری را نشان دهند یا بازخورد و ارزیابی بیشتر ایده را جلب کنند.

نسخه‌هایی که در این مرحله منتشر می‌شوند، گاهی اوقات به عنوان نسخه‌های «پیش آلفا» شناخته می‌شوند.

مرحله توسعه و آزمایش

در این مرحله نرم افزار به طور فعال طبق برنامه در حال نگارش، تست و مستندسازی است. این توسط تیم CMS Maintainer و Release Manager برای سری نرم افزار هماهنگ شده است. به خصوص برای ویژگی های بزرگتر، اگر یک ویژگی بخشی از نسخه بعدی باشد، بخش تولید رأی خواهد داد. به شدت توصیه می شود که ایده ها را در اسرع وقت منتشر کنید و برای ایده تایید کنید.

 

در طول این مرحله، نسخه‌هایی ساخته خواهند شد که دارای برچسب‌های "آلفا"، "بتا" و "نامزد انتشار" هستند.

فاز رهاسازی

نرم افزار زمانی وارد فاز انتشار می شود که اولین نسخه «در دسترس بودن عمومی» در دسترس قرار گیرد. در این مرحله کد با کیفیت تولید و مناسب برای استفاده کاربران عمومی در نظر گرفته می شود.

نسخه‌های منتشر شده در این مرحله مشمول طرح شماره‌گذاری نسخه می‌شوند که نسخه‌سازی معنایی را همانطور که در بخش شماره‌گذاری نسخه این سند توضیح داده شده، الزامی می‌کند.

فاز پشتیبانی

پس از انتشار نسخه x.0.0 وارد مرحله پشتیبانی این سری می شویم. در این مرحله ما در حال رفع اشکالات، ایجاد وصله های منتشر شده هستیم. انتشار وصله فقط برای رفع اشکالات است، ویژگی‌های جدید را می‌توان به نسخه‌های جزئی اضافه کرد تا زمانی که شامل یک شکست سازگاری به نسخه پیشین نباشد.

ما 4 نسخه کوچک را برنامه ریزی می کنیم. آخرین نسخه فرعی یک نسخه بریج(پل) است و حاوی ویژگی های جدیدی نیست و به عنوان آماده سازی برای نسخه اصلی بعدی است. به روز رسانی نسخه اصلی بعدی را فقط می توان از نسخه پل، معمولاً نسخه x.y.4 ایجاد کرد. پس از تاریخ انتشار x.4.0، ما به مدت یک سال در حال رفع اشکالات و برای دو سال رفع اشکالات امنیتی هستیم.

هنگامی که نسخه جزئی بعدی منتشر شد، نسخه نرم افزاری دیگر پشتیبانی نمی شود. به عنوان مثال نسخه x.2.z زمانی که نسخه x.3.0 منتشر می شود از پشتیبانی خارج می شود.

نقاط عطف نرم افزار

چهار نقطه عطف در چرخه انتشار نرم افزار وجود دارد: آلفا، بتا، نامزد انتشار و در دسترس بودن عمومی.

آلفا

نقطه عطف آلفا نشان می دهد که فناوری جدیدی در نرم افزار وجود دارد که برای آزمایش آماده است، اما ویژگی نرم افزار کامل نیست. همچنین ممکن است از نرم‌افزار آلفا برای نشان دادن ترکیبی از ویژگی‌ها استفاده شود تا ببینیم آیا آنها با هم کار می‌کنند یا خیر. برخی از ویژگی ها ممکن است بعدا حذف شوند.

مخاطبان هدف برای انتشار آلفا، جامعه توسعه دهنده شامل توسعه دهندگان شخص ثالث هستند که ممکن است تحت تأثیر تغییرات اصلی یا ویژگی های جدید قرار گیرند.

نرم افزار آلفا برای محیط های تولیدی مناسب نیست.

بتا

نقطه عطف بتا ویژگی کامل در نظر گرفته می شود، اما هنوز برای محیط های تولید مناسب در نظر گرفته نمی شود. این نرم افزار در نظر گرفته شده است که به طور کامل برای مشکلات رگرسیون، امنیت و پایداری آزمایش شود.

توسعه‌دهندگان برنامه‌های افزودنی شخص ثالث باید محصولات خود را در برابر همه نسخه‌های بتا آزمایش کنند و هرگونه مشکلی را در ردیاب مشکل گزارش کنند. انتظار برای یک نامزد آزادی خیلی دیر است.

کاندید آزاد (RC)

هدف یک نامزد انتشار آزمایش بسته بندی نهایی و فرآیند انتشار است تا اطمینان حاصل شود که همه چیز آماده است تا نرم افزار به مرحله انتشار با اولین نسخه در دسترس عمومی برود.

همه برچسب‌های زبان باید قبل از انتشار نامزد انتشار (تجمیع زبان) اضافه شوند.

مهم است که توسعه‌دهندگان برنامه‌های افزودنی شخص ثالث آزمایش‌های نهایی را روی همه نامزدهای انتشار انجام دهند و هر گونه اشکال را فوراً گزارش کنند. با این حال، تنها باگ‌های قابل توجه «show stopper» مربوط به نرم‌افزار اصلی یا برنامه‌های افزودنی موجود در نامزدهای انتشار برطرف می‌شوند. مشکلاتی که فقط بر روی نرم افزارهای شخص ثالث تاثیر می گذارند در این مرحله رفع نمی شوند. هیچ ویژگی اضافه یا حذف نخواهد شد.

نامزدهای انتشار کامل و مناسب برای محیط های تولید در نظر گرفته می شوند، با این حال آنها باید فقط توسط افراد آگاه که خطرات را درک می کنند در تولید مستقر شوند. یک نامزد انتشار این پتانسیل را دارد که به‌عنوان نسخه در دسترس عمومی مجدداً برچسب‌گذاری شود، مگر اینکه مشکلات اساسی ظاهر شود.

در دسترس بودن عمومی (GA)

نقطه عطف در دسترس بودن عمومی نشان می دهد که نسخه بسیار پایدار و مناسب برای کاربران نهایی است. این نسخه تنها زمانی می تواند منتشر شود که تمام مشکلات "Release Blocker" برطرف شده باشد.

شماره گذاری نسخه

انتشار نرم افزار توزیع کد نرم افزار، اسناد و مواد پشتیبانی است. هر نسخه دارای یک شناسه نسخه است که به گونه ای ساختار یافته است که به خوانندگان ایده ای از ارتباط آن با نسخه های دیگر ارائه می دهد.

جوملا از Semantic Versioning (2.0.0) پیروی می کند و این سند نیز از اصطلاحات تعریف شده در آنجا استفاده می کند.

به طور خلاصه، شناسه‌های نسخه برای جوملا از یک قرارداد عددی سه سطحی پیروی می‌کنند که در آن سطوح با اهمیت تغییر تعریف می‌شوند.

عمده.کوچک.پچ

کجا

1. افزایش در شناسه نسخه اصلی نشان دهنده شکست در سازگاری با نسخه پیشین است.
2. افزایش در شناسه نسخه جزئی نشان دهنده اضافه شدن ویژگی های جدید یا تغییر قابل توجه در ویژگی های موجود است.
3. افزایش در شناسه نسخه پچ نشان می دهد که باگ ها برطرف شده اند.

برای جزئیات کامل به مستندات https://semver.org/spec/v2.0.0.html مراجعه کنید. برای اطلاعات بیشتر در مورد آنچه که در محصولات ما سازگاری با نسخه پیشین را تشکیل می دهد، به سازگاری با نسخه پیشین مراجعه کنید.

ارتقاء

هدف ارتقا از یک نسخه از یک محصول به هر نسخه بعدی همیشه ساده و بدون دردسر بودن آن است. با این حال، از آنجایی که به طور واقعی امکان پشتیبانی از ارتقاء مستقیم از یک نسخه دلخواه به هر نسخه دلخواه دیگر وجود ندارد، ما حداقل مسیر ارتقا را تعیین کرده ایم که پشتیبانی خواهد شد.

داشتن این مسیر ارتقاء پشتیبانی شده مهم است زیرا آزمایش این مسیر باید در طول توسعه هر نسخه جدید انجام شود و لازمه پذیرش کد خواهد بود. توسعه‌دهندگان برنامه‌های افزودنی شخص ثالث نیز باید بدانند که این مسیر ارتقاء پشتیبانی‌شده است تا بتوانند اطمینان حاصل کنند که محصولاتشان نیز می‌توانند در همان مسیر ارتقا یا مهاجرت کنند.

ارتقاها باید با یک کلیک ساده باشند. این امکان وجود دارد که برای به روز رسانی به نسخه اصلی بعدی، کاربران باید یک سری مراحل دستی را دنبال کنند تا بتوانند سایت را با موفقیت به روز کنند.

به طور خلاصه، مسیر ارتقای پشتیبانی شده همیشه این است که ابتدا به نسخه جزئی کاملاً وصله‌شده فعلی در سری اصلی که در حال حاضر استفاده می‌شود، ارتقا داده می‌شود، و سپس به‌روزرسانی به آخرین نسخه فرعی کاملاً وصله‌شده در سری بعدی اصلی بعدی.

پچ منتشر می شود

انتشار وصله باید قابلیت اعمال شدن توسط یک فرآیند خودکار با احتمال موفقیت بسیار بالا را داشته باشد.

 

مسیر ارتقای پشتیبانی شده به نسخه بعدی بعدی فرض می‌کند که تمام وصله‌های سری جزئی نصب‌شده فعلی اعمال شده‌اند.

انتشارات جزئی

نسخه‌های کوچک باید با یک فرآیند ارتقا با یک کلیک و با احتمال موفقیت بالا اعمال شوند. از آنجایی که ممکن است ویژگی‌های جدیدی اضافه شده باشد، ممکن است یک نسخه جزئی نیز باگ‌های جدیدی را معرفی کند که متعاقباً در نسخه‌های پچ بررسی می‌شوند. انتشار جزئی ممکن است ثبات را کاهش دهد در حالی که انتشار پچ همیشه باید آن را افزایش دهد. در نتیجه، نسخه‌های جزئی معمولاً باید توسط انسانی انجام شود که می‌تواند آزمایش‌های بعدی را برای اطمینان از موفقیت آمیز بودن ارتقا انجام دهد.

انتشارات اصلی

نسخه‌های اصلی باید بتوانند با یک فرآیند ارتقا با یک کلیک و با احتمال موفقیت بالا اعمال شوند.

مسیر ارتقای پشتیبانی‌شده به نسخه اصلی بعدی، فرض می‌کند که نسخه فرعی نصب‌شده فعلی به آخرین نسخه سری نسخه اصلی وصله شده است. هنگامی که نسخه فرعی نصب شده در حال حاضر به طور کامل وصله شد، سایت را می توان به نسخه اصلی بعدی بعدی ارتقا داد.

نمونه مسیر ارتقاء

به عنوان مثال، فرض کنید که نسخه های فعلی پشتیبانی شده با وصله کامل 4.4.2، 5.4.3 و 6.2.3 هستند. همچنین فرض کنید آخرین پچ برای نسخه کوچک 4.4 4.4.2 بود. ما یک سایت در 4.2.9 داریم که قرار است به آخرین نسخه 6.2.3 به روز شود. سپس مسیر ارتقای پشتیبانی شده شامل دنباله ای از مراحل ارتقای فردی است:

1. وصله های 4.2.9 تا 4.4.2 را اعمال کنید.

2. به روز رسانی از 4.4.2 به 5.4.3.

4. به روز رسانی از 5.4.3 به 6.2.3.

توجه داشته باشید که به‌روزرسانی‌های نسخه‌های پایان عمر، طبق تعریف، پشتیبانی نمی‌شوند. با این حال، به احتمال زیاد آخرین مسیر به روز رسانی پشتیبانی شده به کار خود ادامه خواهد داد.

خط مشی سازگاری با نسخه پیشین

پروژه جوملا به دنبال حفظ سازگاری به نسخه پیشین تا زمانی که ممکن است و سازگاری کامل به نسخه پیشین در یک سری اصلی تضمین شده است. سازگاری به نسخه پیشین ممکن است تنها زمانی از بین برود که یک سری جدید اصلی شروع شود یا در صورت انتشار امنیتی که بدون شکستن سازگاری با نسخه پیشین ساخته نمی شود.

کد تمیز و قابل نگهداری مهم است، اما با گذشت زمان نیاز به حفظ سازگاری به نسخه پیشین نرم افزار را پیچیده تر و کمتر قابل نگهداری می کند. این بدهی فنی فقط در اولین نسخه از یک سری جدید قابل تسکین است.(برای مثال نگاه کنید به: http://martinfowler.com/bliki/TechnicalDebt.html)

گاهی اوقات بهترین راه برای ادامه توسعه، حذف پشتیبانی از برخی عناصر است. این فرآیند منسوخ شدن باید با دقت انجام شود زیرا می تواند منجر به مشکلات سازگاری با نسخه پیشین ماندگی شود.

قابلیت کاربرد

خط مشی سازگاری با عقب ماندگی فقط می تواند برای جنبه های خاصی از نرم افزار اعمال شود و مهم است که این موارد تعریف شوند تا همه روشن باشند و بتوانند محدودیت های آن وعده را درک کنند. به طور کلی، سازگاری به عقب در موارد زیر اعمال می شود:

PHP

تمام کدهای PHP موجود در پوشه /libraries که به‌عنوان خصوصی/داخلی پرچم‌گذاری نشده‌اند و در پوشه فروشنده نیست، بخشی از API جوملا محسوب می‌شوند و مشمول محدودیت‌های سازگاری با عقب هستند.

علاوه بر این، برنامه های افزودنی برای تمدید در نظر گرفته نشده اند. به عنوان مثال: کلاس های افزونه به عنوان نهایی علامت گذاری می شوند و مجاز به استفاده به عنوان پایه برای افزونه های شخص ثالث نیستند. گسترش ArticleModel از com_content در نظر گرفته نشده است.

جاوا اسکریپت

همه توابع و کلاس‌های جاوا اسکریپت که به‌عنوان خصوصی/داخلی پرچم‌گذاری نشده‌اند و مستقیماً با یک برنامه افزودنی مرتبط نیستند.

به عنوان مثال، جاوا اسکریپت موجود در build/media_source/com_content بخشی از این خط مشی نیست. کد موجود در build/media_source/system بخشی از این سیاست است.

طرحواره های(schemata) پایگاه داده

تمام تغییرات طرحواره پایگاه داده باید با یک اسکریپت تبدیل همراه باشد که می تواند برای تبدیل بدون ضرر از طرح قدیمی به جدید اجرا شود.

طرحواره های(schemata) XML

افزودن موجودیت ها و ویژگی های جدید به طور کلی قابل قبول است. تغییر یا حذف آنها نیست.

طرحواره(schemata) JSON

افزودن نهادهای جدید به طور کلی قابل قبول است. تغییر یا حذف آنها نیست.

کلیدهای زبان

تغییر یا حذف یک کلید زبان یک شکست سازگاری با عقب در نظر گرفته می شود. اضافه کردن موارد جدید نیست. تغییر اساسی معنی مرتبط با کلید زبان یک شکست سازگاری است. بیان مجدد چیزی برای توصیف دقیق تر یا دستور زبان en-GB مناسب نیست.

نشانه گذاری ارائه شده

در حال حاضر، نشانه‌گذاری رندر شده مشمول وعده سازگاری ما نیست. ما سعی می‌کنیم نشانه‌گذاری را به گونه‌ای تغییر ندهیم که ممکن است یک سایت متفاوت رندر شود، اما نمی‌توانیم قول بدهیم که در حال حاضر چیزی را خراب نکنیم. ما روی تعریف راه هایی کار خواهیم کرد که از طریق آنها ممکن است قول سازگاری با عقب برای نشانه گذاری در آینده بدهیم، اما در حال حاضر توافق رضایت بخشی در مورد یک استاندارد قابل اجرا نداریم.

CSS

قوانین CSS را می توان به روز کرد اما حذف نشد.

URL ها

هر تغییری در URL که 404 (یا خطاهای دیگر) را در جایی که قبلاً 200 می‌داد می‌دهد، یک شکست در سازگاری با عقب است. با این حال، اگر تغییر منجر به تغییر مسیر به یک URL جدید (که 200 می دهد) شود، قابل قبول است.

به طور کلی، اگر یک URL تغییر کند، به شرطی که URL جدید دقیقا همان منبع ارائه شده را به همان روش ارائه دهد، آنگاه به عنوان یک شکست در سازگاری با عقب تلقی نمی شود. به عنوان مثال، تغییر ترتیب آرگومان ها در قسمت query یک URL به عنوان یک شکست در نظر گرفته نمی شود.

کتابخانه های مورد استفاده

توسعه نرم افزار مدرن اغلب از کتابخانه های سایر ارائه دهندگان نرم افزار استفاده می کند. زمانی که برای رفع یک باگ یا افزایش امنیت لازم باشد، می‌توان آن‌ها را در نسخه‌های کوچک و پچ به‌روزرسانی کرد. این نباید الزامات فنی محصول را تغییر دهد. در چنین مواردی که یک به‌روزرسانی باید اعمال شود، پروژه می‌تواند کتابخانه را فورک کند و از نسخه فورک شده کتابخانه استفاده کند. این یک تصمیم موردی است، اما ما سعی می کنیم از راه حلی با کمترین تأثیر استفاده کنیم.

کتابخانه ها را می توان در نسخه اصلی خود (در صورتی که از استراتژی مشابه SemVer پیروی کنند) در اولین نسخه جزئی یا اصلی جوملا ارتقاء داد. ما همچنین کتابخانه‌ها را در مرحله کاندیدای پیش از انتشار فرآیند توسعه نسخه‌های جزئی و اصلی به‌روزرسانی می‌کنیم.

وابستگی های متعالی یک کتابخانه استفاده شده بخشی از خط مشی b/c نیست.

دیگر کتابخانه‌های مورد استفاده در نسخه اصلی بعدی حذف خواهند شد. ما فایل‌ها را تا زمانی که ممکن است نگه می‌داریم تا سایت‌هایی را که از کتابخانه استفاده کرده‌اند، خراب نکنیم، حتی اگر از کتابخانه در محصول اصلی استفاده نکنیم.

منسوخ شدن

یک عنصر را می‌توان در هر زمانی در چرخه عمر نرم‌افزار به‌عنوان منسوخ‌شده علامت‌گذاری کرد، اما فقط می‌توان آن را در نسخه دوم اصلی پس از نسخه اصلی فعلی حذف کرد. توصیه هایی در مورد نحوه اصلاح کدی که در حال حاضر از عنصری استفاده می کند که به عنوان منسوخ علامت گذاری شده است، باید به مستندات اضافه شود.

عناصر منسوخ باید در اسرع وقت از محصول اصلی حذف شوند.

به عنوان مثال، کدهایی که در نسخه 4.3.5 منسوخ شده اند، برای حذف در نسخه 7.0.0 برنامه ریزی می شوند. کدی که در نسخه 7.0.0 منسوخ شده است را نمی توان تا زمان انتشار نسخه 9.0.0 حذف کرد.

کدی که منسوخ شده است دارای یک برچسب @deprecated به بلاک docblock مناسب خواهد بود که شامل نسخه منسوخ و اولین نسخه حذف می شود. همچنین در راهنمای مهاجرت در manual.joomla.org مستند خواهد شد. و در یادداشت های انتشار ذکر خواهد شد. برچسب باید جایگزینی را توضیح دهد یا یک اخطار اضافه کند که بدون جایگزینی حذف شده است.

به عنوان مثال یک بلوک منسوخ می تواند به شکل زیر باشد:

@deprecated 4.3 در نسخه 6.0 حذف خواهد شد

به جای آن از کلاس \Joomla\Component\Content\Administrator\Service\HTML\Icon استفاده کنید

کلاس‌ها، توابع، متغیرها یا موارد دیگری که به‌عنوان داخلی، نهایی، خصوصی علامت‌گذاری شده‌اند مشمول خط‌مشی منسوخ شدن نیستند و می‌توانند در هر زمانی حذف شوند.

رهبری دپارتمان تولید ممکن است تصمیم بگیرد که حذف عناصر منسوخ را در صورت صلاحدید به تعویق بیندازد.

افزونه سازگاری

کد منسوخ شده را می توان به یک افزونه سازگاری منتقل کرد. این افزونه امکان به روز رسانی نرم تر را بین نسخه های اصلی فراهم می کند. کد نسخه قبلی را نگه می دارد که ممکن است پس از به روز رسانی سایت را خراب کند، زیرا یک برنامه افزودنی از کد منسوخ شده استفاده می کند. یک برنامه افزودنی فقط زمانی کاملاً سازگار است که بدون مشکل با افزونه سازگاری غیرفعال اجرا شود.

افزونه سازگاری پس از یک به روز رسانی عمده فعال می شود.

رگرسیون ها

بدون شک مواردی وجود خواهد داشت که یک نسخه به طور ناخواسته سازگاری با نسخه پیشین را از بین ببرد. اگر یک یا چند رگرسیون سازگاری عقب مانده در یک سری اصلی پیدا شود، با انتشار یک پچ در اسرع وقت پس از کشف آنها رفع خواهند شد.

حداقل الزامات فنی

حداقل الزامات فنی، مانند نسخه PHP، نسخه پایگاه داده و غیره، فقط برای اولین نسخه از نسخه اصلی جدید قابل افزایش است.

تنزل رتبه

تنزل رتبه محصول جوملا پشتیبانی نمی شود. تغییرات ایجاد شده در حین ارتقا ممکن است برگشت ناپذیر باشد. بنابراین اگر پس از ارتقاء با مشکل مواجه شدید، باید از نسخه پشتیبان تهیه شده بلافاصله قبل از ارتقا، بازیابی کنید.

تنزل دادن عنصری که محصول جوملا به آن وابسته است نیز پشتیبانی نمی شود. به عنوان مثال، در حالی که انتقال محصول به یک میزبان جدید با نسخه پایین‌تر از وب سرور، موتور پایگاه داده یا PHP معمولاً کار می‌کند، مشروط بر اینکه عنصر وابسته همچنان در حداقل نیازهای محصول باشد، نمی‌توان تضمین کرد زیرا در برخی موارد داده‌های استفاده شده توسط محصول ممکن است به برخی از ویژگی‌های عنصر وابسته بستگی داشته باشد که قابل برگشت نیست. به عنوان مثال، کاهش رتبه یک کتابخانه رمزگذاری مشکل ساز خواهد بود.

به طور مشابه، انتقال بین انواع عناصر وابسته نیز پشتیبانی نمی شود. به عنوان مثال، انتقال از Postgres به MySQL یا بالعکس، پشتیبانی نمی شود. ممکن است ابزارهای شخص ثالثی در دسترس باشند که بتوانند چنین انتقالی را انجام دهند، اما اینها خارج از محدوده خط مشی پشتیبانی ما هستند.

سیاست امنیتی

سیاست امنیتی برای CMS را می توان در مخزن git یافت.