021-71053903 [email protected] پشتیبانی از شنبه تا چهارشنبه ساعت 9 الی 16

PEP 6 – Bug Fix Releases

pep6 - status

abstract – انتزاعی

پایتون در طول تاریخ تنها یک fork توسعه داشته که تمام نسخه های منتشر شده دارای هدفی ترکیبی برای اضافه کردن ویژگی های جدید و رفع اشکال(bug fix) بودن(این دسته از نسخه های منتشر شده به عنوان نسخه های اصلی شناخته میشوند.)

این PEP توضیح میدهد که چگونه باگ ها رو فیکس کنیم fork ها را  جدا کنیم و از کدها نگهداری کنیم و نسخه های قدیمی را برای هدف اصلی رفع اشکال(bug fix) شرح میدهد.

این PEP یک تضمین برای رفع اشکال(bug fix) کردن نسخه های منتشر شده نیست!

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

Motivation – انگیزه

با انتقال پایتون به SourceForge توسعه این زبان شتاب گرفت.

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

افراد زیادی از بروزرسانی های و ویژگی های جدید پایتون ناراحت نیستند و گاها رفع اشکال(bug fix) کردن پس از اضافه کردن ویژگی های جدید طول میکشید که این باعث تاخییر در چرخه توسعه میشد.

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

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

Prohibitions – ممنوعیت

نسخه های که برای رفع اشکال(bug fix)  منتشر میشوند ملزم هستند که از چند محدودیت تخطی نکنند که عبارتند از:

  1. هیچ تغیراتی در سینتکس به وجود نمیاید و تمامی فایل های .pyc و .pyo باید کار کنند(بدون نیاز با بازسازی) با تمام نسخه های رفع اشکال باید یک fork جدا از نسخه ای اصلی باشند.
  2. هیچ تغییری در pickle ها رخ ندهد
  3. نباید هیچ تغییر ناسازگاری با C API رخ دهد. تمامی اکستنشن ها باید به کارشان بدون کمپایل دوباره در همان fork درست مانند نسخه اصلی ادامه دهند.

نقض هر یک از این محدودیت ها به یک اعلامیه BDFL نیاز دارد(و یک هشدار برجسته در یادداشت های نسخه انتشار)

ممنوعیت(در صورت امکان بهتر است از این محدودیت ها  اعمال شود)

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

  1. اضافه نکردن ویژگی های جدید، هدف از انتشار نسخه های Bug Fix ، اضافه کردن ویژگی جدید نیست.
  2. یک بروزرسانی بدون اعصاب خردی ارائه دهید.کاربران باید مطمئن شوند یک بروزرسانی از نسخه 3.x.y  به نسخه 3.x.(y+1) سیستم های در حال اجرایشان را خراب نمیکند(مشکلات از قبیل هنگ کردن – crash  کردن) یعنی تا وقتی که لازم نشده نباید کتابخانه های استاندارد یا حتی بدتر API ها تغییر کنند.

Applicability of Prohibitions – کاربرد ممنوعیت ها

تمام ممنوعیت های اصلی و پیشنهای بالا برای هر دو نسخه نهایی و رفع اشکال اعمال میشود(برای مثال از 3.8 به نسخه 3.8.1 و همچنین از نسخه 3.8.1 به نسخه 3.8.2)

پیروی کردن از ممنوعیت های لیست شده در این PEP باعث میشود که تمام جامعه پایتون خوشحال باشند از انتشار یک نسخه رفع اشکال و یک بروزرسانی بدون سردرد و ایمن.

Helping the Bug Fix Releases Happen – کمک به انتشار نسخه رفع اشکال

در این قسمت چند نکته برای کمک به انتشار نسخه رفع اشکال در کنار هم اورده شده.

  1. رفع اشکال backport . اگه شما میتوانید یک باگ را درست کنید(رفع اشکال کنید) و به نظر مناسب است آنرا به شعبه های CVS منتقل کنید برای نسخه رفع اشکال کنونی.اگر شما تمایل ندارید و یا نمیتوانید از آن پشتیبانی کنید، یک یاداشت در commit message با کلماتی مثل  ‘Bugfix candidate’ یا  ‘Backport candidate’بنویسید.
  2. اگر شما مطمئن نیستید. بپرسید.از کسی که مسئول مدیریت نسخه های Bug Fix کنونی بر عهده اوست سوال کنید که به نظرشان این نسخه مناسب است ؟
  3. اگر یک مشکل خاص وجود دارد  و شما میخواهید که در نسخه رفع اشکال برطرفش کنید، بالا و پایین کد را چک کنید و سریع و سعی کنید مشکل را برطرف کنید و منتظر نباشید 48 ساعت بگذرد و درخواست رفع اشکال کنید.

Version Numbers – شماره نسخه

با شروع پایتون نسخه 2.0 تمام نسخه های ملزم بودن از یک شماره نسخه با فرم X.Y استفاده کنند و این در نسخه های رفع اشکال به شکل X.Y.Z است.

نسخه فعلی تحت توسعه به عنوان نسخه منتشر شده N شناخته میشود.نسخه ی که به تازگی منتشر شده به عنوان N-1 شناخته میشود.

در CVS، نسخه های رفع اشکال در یک شاخه اتفاق میافتد. برای نسخه 2.x شاخه ای به اسم ‘release2x-maint’ نام گذاری شده. برای مثال شاخه ای که  برای پشتیبانی و رفع مشکلات نسخه 2.3  است release23-maint نام دارد

Procedure – روند

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

Patch Czar هماهنگ BDFL برای انتشار نسخه رفع اشکال است.

به هر حال BDFL  با مصوباتی از پیش تعیین شده برای حفظ قدرت veto بر روی تمامی پچ های شخصی است.

یک Patch Czar ممکن است تنها یک شاخه از توسعه را دنبال کند. صد در صد این امکان وجود دارد که افراد متفاوی نسخه های 2.3.x  و 2.4.x را پشتیبانی کند

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

به علاوه هر کسی در جامعه پایتون میتواند پیشنهاد های را برای پچ کردن نقص ها بدهد.

پچ های که که مخصوصا برای نسخه های رفع اشکال منتشر میشوند باید دستورالعمل های PEP3 را دنبال کنند.

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

Patch czar  تصمیم میگیرد که چه تعداد پچ برای انتشار کافی است.

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

اگر باگ های جدیدی پیدا شد آنها باید سریعا برطرف شوند و نسخه رفع اشکال جدید منتشر شود(با شمار نسخه های بیشتر)

برای چرخه 2.3.x patch czar (آنتونی) تقریبا هر شش ماه برای یک نسخه برای انتشار تلاش کرده، اما این برای نسخه های جدید ملزم نیست!

انتظار میرود نسخه های Bug Fix هر شش ماه یک بار اتفاق بیافتند، با این حال این فقط یک راهنمایی است.

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

به طور کلی، فقط نسخه N-1 هر زمانی تحت پشتیبانی قرار میگیرد.یعنی نسخه 2.4 تحت توسعه است حتی زمانی که هنوز نسخه 2.3 در حال انتشار نسخه های Bug Fix است.

اما اگر کسی مشتاق است که نسخهای قدیمی تر را پشتیبانی کند مشکلی ندارد.

Patch Czar History – تاریخ Patch Czar

Anthony Baxter is the Patch Czar for 2.3.1 through 2.3.4.

Barry Warsaw is the Patch Czar for 2.2.3.

Guido van Rossum is the Patch Czar for 2.2.2.

Michael Hudson is the Patch Czar for 2.2.1.

Anthony Baxter is the Patch Czar for 2.1.2 and 2.1.3.

Thomas Wouters is the Patch Czar for 2.1.1.

Moshe Zadka is the Patch Czar for 2.0.1.

History – تاریخ

این PEP به عنوان یک پرپزال در زبان برنامه نویسی پایتون خلق شد.

نسخه اصلی پیشنهاد میکند که یک پچ جدا برای نسخه N-1 منتشر شود در صورتی که نسخه N در حال حاضر در حال انتشار است. نسخه اصلی همچنان به دلیل سیاست های سختگیرانه به دنبال رفع اشکال است.

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

سپس بحث به python-dev منتقل میشود، جایی که در نهایت  BDFL اعلامیه ای مبنی بر روند انتشار نسخه رفع اشکال پایتون را در Tcl صادر میکند.

چیزی که اساسا تنها در مدت شروع N-1 و رفع اشکال به پروپوزال اصلی برگردانده میشود .

اما اجازه انتشار چند نسخه Bug Fix را تا انتشار نسخه N را میدهد.

رفرنس: PEP6

مقاله مرتبط:PEP 4 در پایتون چیست؟

محمد حجازی

31 مطلب منتشر شده

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

درباره این مطلب نظر دهید !

محصولات فروش پایتونی ها

%60
تخفیف

آموزش فیگما (Figma)

30,000 تومان
3
%69
تخفیف

آموزش برنامه نویسی پایتون

35,000 تومان
2