מדיניות גרסאות

שחרורים יציבים

שחרורי React יציבים (מוכרים גם כערוץ “Latest”) פועלים לפי עקרונות גרסה סמנטית (סמבר).

כלומר, במספר גרסה x.y.z:

• כשמשחררים תיקוני באגים קריטיים, מבצעים שחרור תיקון על ידי שינוי המספר z (דוגמה: 15.6.2 ל-15.6.3).
• כשמשחררים יכולות חדשות או תיקונים לא קריטיים, מבצעים שחרור קטן על ידי שינוי המספר y (דוגמה: 15.6.2 ל-15.7.0).
• כשמשחררים שינויים שוברים, מבצעים major release על ידי שינוי המספר x (דוגמה: 15.6.2 ל-16.0.0).

שחרורי גדול יכולים לכלול גם חדשות, וכל שחרור יכול לכלול תיקוני באגים.

שחרורי מינור הם סוג השחרור הנפוץ ביותר.

שינויים שוברים

שינויים שוברים לא נוחים לכולם, אז אנחנו מנסים לצמצם את מספר שחרורי ה-major. לדוגמה, React 15 שוחרר באפריל 2016, React 16 בספטמבר 2017, ו-React 17 באוקטובר 2020.

אנחנו משחררים יכולים בגרסת קטין. לכן שחרורי מינור נוהגים מעניינים ומשמעות יותר מ-major, למרות השם הצנוע שלהם.

מחויבות ליציבות

כשאנחנו משנים את React לאורך זמן, אנחנו מנסים לצמצם את המאמץ שנדרש כדי ליהנות מיכולות חדשות. כשאפשר, נשמור על API ישן עובד גם אם זה אומר אותו לחבילה נפרדת. לדוגמה, לא ממליצים על mixins כבר שנים, אבל עדיין יש להם תמיכה באמצעות create-react-class, ובסיסי קוד רבים ממשיכים להשתמש בהם בקוד לגאסי יציב.

יותר ממיליון מפתחים משתמשים ב-React, וביחד מתחזקים מיליוני קומפונטות. בבסיס הקוד של פייסבוק לבדו יש יותר מ-50,000 קומפונטות React. אנחנו צריכים להפוך את השדרוג לגרסאות חדשות לקל ככל האפשר. אם יתבצע שינויים גדולים בלי נתיב מיגרציה, אנשים יתקעו על גרסאות ישנות. אנחנו בודקים את נתיבי השדרוג האלה גם ב-Facebook עצמה. אם אפשר לעדכן יותר מ-50,000 קומפוננטות, אנחנו מקווים שנוכל יהיה לנהל את השדרוג. בהרבה מקרים אנחנו כותבים סקריפטים אוטומטיים לשדרוג תחביר קומפוננטות, ואז מפרסמים אותם בקוד פתוח כדי שכולם יוכלו להשתמש.

שדרוגים הדרגתיים דרך אזהרות

גרסאות הפיתוח של React כוללות הרבה אזהרות מועילות. כשאפשר, אנחנו משתמשים אזהרות כהכנה לשינויים שוברים עתידיים. כך, אם לאפליקציה שלך אין אזהרות בגרסה האחרונה, היא תהיה תואמת גם לגרסת הבאה. זה יכול לשדרג אפליקציות קומפונטה אחרי קומפונטה.

אזהרות פיתוח לא משפיעות על התנהגות זמן הריצה של האפליקציה. אתה יכול להיות בטוחים שהאפליקציה תתנהג אותו הדבר בין בניית פיתוח ל-build ייצור. ההבדלים היחידים הם שבייצור לא יופיעו אזהרות, וה-build יעיל יותר. (אם אני אראה משהו אחר, בעיה של פתחו.)

מה נחשב לשינוי שובר?

בדרך כלל אנחנו לא מעלים מספר שינויים גדולים ב:

• אזהרות פיתוח. איך שהן לא משפיעות על ייצור, אנחנו משתמשים אזהרות חדשות או לשנות אזהרות קיימות גרסאות major. למעשה, זה מה שמאפשר לנו להתריע בצורה אמינה על שינויים עתידיים.
• **APIs שמתחילים ב-unstable_.**יין אלה יכולות ניסיוניות שעד אין לנו ביטחון מלא ב-API שלהן. שחרור עם הקידומת unstable_ לאפשר לנו להתקדם מהר יותר ולהגיע מוקדם יותר ל-API יציב.
• גרסאות אלפא ו-קנרי של React. אנחנו צריכים לספק גרסאות אלפא כדי חדשות מוקדם, אבל לבצע שינויים לפי מה שנלמד בתקופת האלפא. אם משתמשים בגרסאות האלה, חשוב לדעת ש-APIs יכולים להשתנות לפני שחרור יציב.
• APIs לא מתועדים ומבני נתונים פנימיים. אם ניגשים לשמות פנימיים כמו __SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED או __reactInternalInstance$uk43rzhitjg, אין שום הבטחה. אתם לבד.

המדיניות פרגמטית: אנחנו לא רוצים לעזור לכם כאב ראש. אם היינו מעלים גדולים על כל השינויים האלה, היינו מוציאים הרבה יותר גרסאות גדולות ובסוף גורמים ליותר כאב סביב ניהול גרסאות בקהילה. זה גם היה מאט אותנו בשיפור React.

עם זאת, אם אנחנו מצפים ששינוי מרשימה זו יגרום בעיות רחבות בקהילה, עדיין נעשה כמיטב יכולתנו לספק נתיב מיגרציה הדרגתי.

אם בגרסת קטין אין חדשות, למה זו לא גרסת תיקון?

יכול שגרסת מינור לא תכלול יכול חדשות. סמבר אפשרי זאת, וקובע ש-”[גרסה מינורית] עשויה מוגברת אם יוצגו פונקציות או שיפורים משמעותיים בקוד פרטי. זה עשוי לכלול שינויים ברמת התיקון.”

ובכל זאת עולה השאלה למה לא לגרס את השחרורים האלה כ-patch.

התשובה היא שכל שינוי ב-React (או בכל תוכנה אחרת) נושא סיכון לשבירה לא צפויה. דמיינו מצב שבו תיקון שמתקן באג אחד מכניס בטעות באג אחר. זה לא רק מפריע למפתחים, אלא גם מזיק במון בגרסאות תיקון עתידיות. זה מצער במיוחד שהתיקון המקורי נו לבאג שכמעט לא פועד בפועל.

יש לנו היסטוריה טובה של שחרורי React נקיים מבאגים, אבל תיקון לגרסאות יש רף אמינות אפילו גבוה יותר כי רוב המפתחים מנחים אפשר לאמץ ללא השלכות שליליות.

אנחנו שומרים שחרורי תיקון רק לבאגים הקריטיים ביותר ולפגיעויות אבטחה.

אם שחרור כולל שינויים לא חיוניים, למשל ריפקטור פנימי, שינויים בפרטי מימוש, שיפורי ביצועים או תיקוני באגים קטנים, נעלה את גרסת ה-minor גם אם אין אפשרות חדשות.

כל ערוצי ההפצה

React נשענת על קהילת קוד פתוח פעילה שמדווחת באגים, פותחת בקשות משיכה ו-מגישה RFCs. כדי לעודד משוב אנחנו לפעמים משתפים גרסאות מיוחדות של React שכוללות יכולות שעדיין לא שוחררו.

כל ערוץ הפצה של React נועד להשתמש בשימוש:

• Latest מיועד_לגרסאות T1 יציבות לפי semver. זה מה שמקבלים כשמתקינים React מ-npm. זה הערוץ שבו אתם כבר משתמשים היום. אפליקציות למשתמשי קצה שצורכות React למעשה משתמשות בערוץ הזה.
• Canary עוקב אחרי הענף של מאגר הקוד של React. אפשר לחשוב עליו כעל לשחרר מועמדים לגרסת. Frameworks או setups מנעולים אחרים יכולים לבחור בערוץ הזה עם גרסה נעולה של React. אפשר גם להשתמש ב-Canary לבדיקות אינטגרציה בין React לפרויקטי צד שלישי.
• ניסיוני כולל APIs ויכולות ניסיוניות שלא זמינות בגרסאות יציבות. גם הערוץ הזה עוקב אחרי הענף טפסים, אבל עם דגלי יכולים עוד מופעלים. משתמשים בו כדי לנסות אפשרויות לפני שחרור.

כל הגרסאות מתפרסמות ל-npm, אבל רק משתמש אחרון בגרסאות סמנטיות. גרס קדם-הוצאה (בערוצי Canary and-Experial) מקבלות מספר גרסה תכונות מ-hash של התוכן ותאריך הקומיט, למשל 18.3.0-canary-388686f29-20230503 עבור Canary ו-0.0.0-experimental-388686f29-20230503 עבור Experimental.

גם אחרון וגם Canary נתמכים רשמית לאפליקציות למשתמשי קצה, אבל עם ציפיות שונות:

• גרסאות Latest פועלות לפי מודל סמבר המסורתי.
• גרסאות Canary חייבות להיות נעולות לגרסה ולולות לכלול שינויים שוברים. הן מיועדות ל-setup מנוהל (כמו מסגרות) שרוצה לשחרר יכולות חדשות ותיקוני באגים של React בקצב שחרור משלו.

גרסאות ניתנות נסיונית לצורכי בדיקה בלבד, ואין לנו הבטחה שההתנהגות לא תשתנה בין שחרורים. הן לא פועלות לפי סבר כמו הערוץ אחרון.

פרסום גרסאות מראש לאותו רג’יסטרי שבו משתמשים אנחנו לגרסאות יציבות לנו להיעזר בכלים שתומכים בזרימת העבודה של npm, כמו unpkg ו-CodeSandbox.

ערוץ אחרון

Latest הוא הערוץ של גרסאות React יציבות. הוא תואם לתגית latest ב-npm. זה הערוץ המומלץ לכל אפליקציות React שמופצות למשתמשים אמיתיים.

אם לא בטוחים באיזה ערוץ לבחור, לבחור אחרון. אם אתם משתמשים ב-React, זה כנראה מה שאתם כבר עושים. אפשר לראות לעדכונים יציבים מאוד בערוץ הזה. המספור פועל לפי סמר, כפי ש-תואר קודם.

ערוץ קנרי

ערוץ Canary הוא ערוץ שעוקב אחרי הענף טפסים של מאגר React. אנחנו משתמשים בשחרורי Canary כ-release candidates לערוץ אחרון. אפשר לראות ב-Canary superset של האחרון שמתעדכן בתדירות גבוהה יותר.

רמת השינוי בין שחרור Canary האחרון לשחרור האחרון דומה בקירוב למה שרואים בין שתי גרסאות מינור ב-semver. עם זאת, ערוץ Canary לא עומד בגירסאות סמנטיות. יש לצפות לשינויים שוברים מדי פעם בין שחרורים עוקבים בערוץ הזה.

אל תשתמשו ב-prerelease באפליקציה למשתמשי קצה אלא אם אתם פועלים לפי תהליך Canary.

שחרורי קנרי מתפרסמים עם התגית canary ב-npm. הגרסאות נוצרות מ-hash של תוכן הבנייה ותאריך הקומיט, למשל 18.3.0-canary-388686f29-20230503.

שימוש בערוץ canary לבדיקות אינטגרציה

ערוץ Canary תומך גם בבדיקות אינטגרציה בין React לפרויקטים אחרים.

כל שינוי ב-React עוברים רופאים רופאים שנעשו לפני שהוא מגיע לצי. אבל באקו-סיסטם של React יש אינספור סביבות וקונפיגורציות, ואי אפשר לבדוק כולן.

אם אתם מחברי מסגרת, ספרייה, כלי פיתוח או פרויקט תשתיתי דומה עבור React, אפשר לעזור לנו לשמור על יציבות React למשתמשים שלכם ולכל הקהילה על ידי רצונה תקופתית של חב הבדיקות מול השינויים. אם זה רלוונטי עבורכם, פעלו כך:

• הגדירו cron job בפלטפורמת ה-CI המועדפת עליכם. גם CircleCI וגם Travis CI תומכות.

• בתוך ה-cron job עדכנו את חבילות React לגרסה האחרונה בערוץ Canary באמצעות התגית canary ב-npm. עם npm cli:

  npm update react@canary react-dom@canary

או עם חוט:

yarn upgrade react@canary react-dom@canary

• הריצו את חבילת הבדיקות שלכם מול החבילות המעודכנות.
• אם הכול עובר, מצוין. סביר שהפרויקט שלכם יעבוד גם עם גרסת ה-minor הבאה של React.
• אם משהו נשבר בצורה לא צפויה, עדכנו אותנו על ידי פתיחת בעיה.

פרויקט שמשתמש הזה הוא Next.js. אפשר לראות את קונפיגורציית CircleCI שלהם כדוגמה.

ערוץ ניסיוני

כמו קנרי, גם Experimental הוא ערוץ שעוקב אחרי הענף טפסים של מאגר React. בשונה מ-Canary, Experimental שחרור יכול ו-APIs נוספים שעדיין לא מוכנים לשחרור רחב.

בדרך כלל, עדכון ל-Canary ילווה בעדכון מקביל ל-Experimental. שניהם מבוססים על אותו גרסת מקור, אבל נבנים עם סט דגלי יכול שונה.

שחרורי ניסויים יכולים להיות שונים אקס מ-Canary ומ-Latest. אל תשתמשו בשחרורי ניסיוני באפליקציות למשתמשי קצה. יש לצפות לשינויים שוברים תכופים בין שחרורים בערוץ הזה.

שחרורי ניסיוני מתפרסמים עם התגית experimental ב-npm. הגרסאות נוצרות מ-hash של תוכן הבנייה ותאריך הקומיט, למשל 0.0.0-experimental-68053d940-20210623.

מה נכנס לשחרור ניסיוני?

יכולות ניסיוניות הן יכולות שעדיין לא מוכנות לשחרור רחב, ועלולות להשתנות בצורה דרמטית לפני שהן נסגרות סופית. חלק מהניסויים לעולם לא יבשילו. הסיבה לקיומם היא בדיקת ההיתכנות של שינויים מוצעים.

למשל, אם ערוץ ניסיוני היה קיים כשפרסמנו את Hooks, היינו משחררים את Hooks לערוץ נסיוני שבועות לפני שהיו זמינים ב-Latest.

אפשר שיהיה לכם ערך בהרצת בדיקות אינטגרציה מול ניסיוני. זו החלטה שלך. עם זאת, חשוב להבין ש-ניסיוני אפילו פחות מ-קנרי. אנחנו לא מבטיחים יציבות בין שחרורי ניסיוני.

איך אפשר ללמוד עוד על יכולות ניסיוניות?

ניסיוניות עשויות להיות מתועדות או שלא. בדרך כלל אנחנו לא מתעדים ניסויים עד שהם קרובים לשחרור ב-Canary או ב-Latest.

אם אתה יכול לא מתועדת, יש לך אפשרות RFC.

פרסם ב-בלוג React כשנהיה מוכנים על ניסויים חדשים, אבל זה לא אומר את כל הניסויים.

תמיד אפשר לעקוב אחרי ההיסטוריה במאגר GitHub הציבורי שלנו כדי לקבל רשימה מלאה של השינויים.