انتشارات ​

در حال بررسی برای آخرین نسخه…

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

چرخه‌ی انتشار ​

ویو یک چرخه‌ی انتشار ثابت ندارد.

• انتشارات وصله‌ای هر زمان که نیاز باشند، منتشر می‌شوند.

• انتشارات minor همیشه ویژگی‌های جدیدی دارند، با مدت زمانی معمولاً ۳ تا ۶ ماهه. انتشارات minor همیشه از فاز پیش‌انتشار بتا عبور می‌کنند.

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

حالات استثنایی نسخه‌بندی معنایی ​

انتشارات ویو از قاعده‌ی نسخه‌بندی معنایی با چند استثنا پیروی می‌کنند.

تعاریف تایپ‌اسکریپت ​

ما شاید که تغییرات ناسازگری به تعاریف تایپ‌اسکریپت بین نسخه‌های minor بدهیم. علت این کار:

1. گاهی اوقات خود تایپ‌اسکریپت تغییرات ناسازگار بین نسخه‌های minor خود ارائه می‌دهد و ما مجبور می‌شویم که تایپ ها را مطابق با نسخه‌های جدیدتر تایپ‌اسکریپت تطبیق دهیم.

2. گه‌گاهی، ما نیاز داریم که از ویژگی‌هایی که فقط در نسخه‌های جدیدتر تایپ‌اسکریپت هست استفاده کنیم که این کار به افزایش نسخه‌ی موردنیاز تایپ‌اسکریپت می‌انجامد.

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

سازگاری کد کامپایل شده با runtime قدیمی‌تر ​

یک نسخه‌ی minor جدیدتر از کامپایلر vue می‌تواند کدی بسازد که با runtime ویو از یک نسخه‌ی قدیمی‌تر minor ناسازگار باشد. برای مثال، کدی که توسط کامپایلر نسخه‌ی ۳.۲ تولید شده شاید کاملاً با runtime ویو نسخه‌ی ۳.۱ سازگار نباشد.

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

پیش‌انتشارات ​

نسخه‌های minor معمولاً پیش از انتشار نسخه‌های بتای با تعداد نامشخصی دارند. نسخه‌های major از فازهای آلفا و بتا عبور می‌کنند.

به علاوه، ما انتشارات canary را هر هفته از branchهای main و minor بر روی گیت‌هاب عرضه می‌کنیم. آن‌ها به عنوان بسته‌های متفاوتی عرضه می‌شوند تا npm متادیتای کانال پایدار را دچار مشکل نکند. شما می‌توانید آن‌ها را با دستور npx install-vue@canary یا npx install-vue@canary-minor نصب کنید.

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

منسوخ شدن ​

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

RFCها ​

قابلیت‌های جدید با تغییرات اساسی بخش کارکرد API و تغییرات زیاد به ویو از طریق پروسه‌ی درخواست برای نظرخواهی (RFC) عبور می‌کنند. پروسه‌ی RFC تلاش می‌کند تا بتوان یک راه پایدار و مدیریت شده برای قابلیت‌های جدیدی که به framework اضافه می‌شوند ساخت و به کاربران فرصت مشارکت و ارائه‌ی بازخوردها را در پروسه‌ی طراحی می‌دهد.

پروسه‌ی RFC در مخزن vuejs/rfcs بر روی گیت‌هاب مدیریت می‌شود.

ویژگی‌های تجربی ​

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

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