כאן תמצאו מידע על טיפול בתאימות לאחור, כולל העברה מגרסה אחת לגרסה אחרת ואיך להעביר שינויים לא תואמים.
Bazel מתפתחת. גרסאות משניות שהופצו כחלק מהגרסה הראשית של LTS תואמות באופן מלא. שינויים בגרסאות LTS גדולות עשויים לכלול שינויים לא תואמים שמצריכים מאמץ מיגרציה מסוים. למידע נוסף על אופן הפעולה של קצב ההפצה של Bazel, קראו את המאמר הודעה על השקת תמיכה לטווח ארוך (LTS) של Bazel.
סיכום
- מומלץ להשתמש ב-
--incompatible_*סימונים כדי לשבור שינויים. - בכל דגל של
--incompatible_*, בעיית GitHub מסבירה את השינוי בהתנהגות ומטרתה לספק מתכון להעברה. - ממשקי API והתנהגות ששומרים על ידי
--experimental_*עשויים להשתנות בכל שלב. - לעולם אין להפעיל גרסאות build עם סימונים
--experimental_*או--incompatible_*.
איך לפעול בהתאם למדיניות הזו
- למשתמשי Bazel – איך לעדכן את Bazel
- לתורמים – שיטות מומלצות בנוגע לשינויים לא תואמים
- למנהלי גרסאות – איך מעדכנים תוויות של גרסאות ואיך מפרסמים גרסאות?
מהי פונקציונליות יציבה?
באופן כללי, ממשקי API או התנהגות ללא סימונים של --experimental_... נחשבים כתכונות יציבות ונתמכות ב-Bazel.
תכנים מהסוג הזה כוללים:
- השפה וממשקי ה-API של Starlark
- כללים בחבילה עם Bazel
- ממשקי API של Bazel כגון ממשקי ביצוע מרחוק או פרוטוקול Event Build
- דגלים והסמנטיקה שלהם
שינויים לא תואמים ומתכונים להעברה
לצורך כל שינוי שאינו תואם לגרסה חדשה, צוות Bazel מנסה לספק מתכון להעברה שעוזר לכם לעדכן את הקוד (קובצי BUILD ו-.bzl, וכן שימוש ב-Bazel בסקריפטים, שימוש ב-Bazel API וכו').
לשינויים שאינם תואמים אמור להיות סימון --incompatible_* משויך ובעיה תואמת ב-GitHub.
עדכונים על שינויים לא תואמים
המקור העיקרי למידע על שינויים לא תואמים הוא בעיות ב-GitHub מסומנות בתווית "incompatible-change" .
בכל שינוי לא תואם, הגורמים לכך הם:
- שם הדגל ששולט בשינוי שאינו תואם
- תיאור של הפונקציונליות שהשתנתה
- מתכון להעברה
כאשר שינוי לא תואם מוכן להעברה עם Bazel בכתובת HEAD (כלומר, גם עם הגרסה הבאה של Bazel מתגלגלת), יש לסמן אותו באמצעות התווית migration-ready. בעיית השינוי הלא תואמת נסגרת אם הדגל הלא תואם מתחלף ב-HEAD.