ניהול גרסאות תוכנה

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

לעיתים קרובות עוקבים אחר תוכנות מחשב מודרניות באמצעות שתי שיטות שונות של ניהול גרסאות תוכנה: מספר גרסה פנימי שעשוי להיות מוגדל פעמים רבות ביום אחד, כגון מספר ממערכת בקרת גרסאות, וגרסת מהדורה שבדרך כלל משתנה בתדירות נמוכה יותר, כגון ניהול גרסאות סמנטיותPreston-Werner, Tom (2013).
Semantic Versioning 2.0.0. Creative Commons.
Retrieved from https://semver.org/spec/v2.0.0.html. או שם קוד של פרויקט.

 היסטוריה 
מספרי קבצים שימשו במיוחד במינהל הציבורי, כמו גם בחברות, לזיהוי ייחודי של קבצים או תיקיות. עבור קובצי מחשב נוהג זה הוצג לראשונה עם מערכת הקבצים ITS של MIT, מאוחר יותר מערכת הקבצים TENEX עבור PDP-10 בשנת 1972.TENEX, a paged time sharing system for the PDP - 10, Bobrow, Burchfiel, Murphy, Tomlinson, March 1972, Communications of the ACM 15(3):135-143.

מאוחר יותר נוספו רשימות של קבצים כולל גרסאותיהם והתלות ביניהם. הפצות לינוקס כמו Debian, עם ה-dpkg שלה, יצרו בשלב מוקדם תוכנה לניהול חבילות שיכולה לפתור תלויות בין החבילות שלהן. הניסיון הראשון של דביאן היה שחבילה הכירה חבילות אחרות התלויות בה. משנת 1994 הרעיון הזה שונה, כך שחבילה צריכה לדעת בעצמה את החבילות שהיא צריכה. בעת התקנת חבילה, נעשה שימוש בפענוח תלויות כדי לחשב אוטומטית מהן החבילות הדרושות, ולהתקין גם אותן עם החבילה הרצויה. כדי להקל על השדרוגים, נעשה שימוש בגרסאות מינימום של חבילות. לפיכך, שיטת המספור הייתה צריכה לדעת איזו גרסה חדשה יותר מהגרסה הנדרשת.package interdependencies, Robert Sanders, 1994-02-25.[<https://lists.debian.org/debian-devel/1995/07/msg00085.html Bug#1167: ELF development packages fail or have missing dependencies], Ian Jackson, 1995-07-30.A Brief History of Debian, Javier Fernández-Sanguino et al, 2021-10-26.

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

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

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

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

 גרסאות סמנטיות 
ממוזער| מספר גרסה סמנטי משלושה חלקים
גרסאות סמנטיות (באנגלית Semantic Versioning או בקיצור SemVer)Preston-Werner, Tom (2013).
Semantic Versioning 2.0.0. Creative Commons.
Retrieved from https://semver.org/spec/v2.0.0.html. היא שיטת גרסאות בשימוש נרחב המקודדת גרסה לפי מספר גרסה של שלושה חלקים (עיקרי.מינורי.תיקון ובאנגלית: Major.Minor.Patch), תג טרום-הפצה אופציונלי ומטא תג בנייה אופציונלי. בשיטה זו, סיכון ופונקציונליות הם המדדים למשמעות. שינויים שוברים מסומנים על ידי הגדלת המספר העיקרי (סיכון גבוה); תכונות חדשות, לא שוברות, מגדילות את המספר המינורי (סיכון בינוני); וכל שאר השינויים הלא-שוברים מגדילים את מספר התיקון (הסיכון הנמוך ביותר). הנוכחות של תג טרום-הפצה (-alpha, -beta) מעידה על סיכון משמעותי, וכך גם מספר עיקרי של אפס (), המשמש לציון עבודה בתהליך שעשויה להכיל כל רמה של פוטנציאל שבירת שינויים (הסיכון הגבוה ביותר). כדוגמה להסקת תאימות מגרסת SemVer, תוכנה המסתמכת על גרסה 2.1.5 של ממשק תכנות יישומים תואמת לגרסה 2.2.3, אך לא בהכרח ל-3.2.4.

מפתחים עשויים לבחור לקפוץ מספר גרסאות קטנות בו-זמנית כדי לציין שנוספו תכונות משמעותיות, אך אינן מספיקות כדי להצדיק הגדלת מספר גרסה עיקרי; לדוגמה, Internet Explorer 5 מ-5.1 עד 5.5 או Adobe Photoshop 5 שקפץ ישר ל-5.5. זה עשוי להיעשות כדי להדגיש את ערך השדרוג למשתמש התוכנה או, כמו במקרה של אדובי, כדי לייצג מהדורה באמצע הדרך בין גרסאות מרכזיות (אם כי רמות של גרסאות מבוססות רצף אינן מוגבלות בהכרח לספרה אחת, כמו בבלנדר גרסה 2.91 או Minecraft Java Edition החל מ-1.7.10).

גישה שונה היא להשתמש במספרים העיקריים והמינוריים יחד עם מחרוזת אלפאנומרית המציינת את סוג השחרור, למשל "אלפא" (a), "בטא" (b), או "מועמד לשחרור" (rc). רכבת שחרור תוכנה המשתמשת בגישה זו עשויה להיראות כמו 0.5, 0.6, 0.7, 0.8, 0.9 → 1.0b1, 1.0b2 (עם תיקונים מסוימים), 1.0b3 (עם תיקונים נוספים) → 1.0rc1 (אשר, אם הוא יציב מספיק), 1.0rc2 (אם נמצאו באגים נוספים) → 1.0. קיים נוהג נפוץ בשיטה זו לא להכניס תכונות חדשות ושינויים שוברים במהלך שלבי המועמדים לשחרור, ולחלק מהצוותים, אפילו גרסאות בטא ננעלות לתיקוני באגים בלבד, כדי להבטיח התכנסות למועד היעד של המהדורה.

 דרגת תאימות 
חלק מהפרויקטים משתמשים במספר הגרסה הראשי כדי לציין מהדורות לא תואמות. שתי דוגמאות הן Apache Portable Runtime (APR) ו-FarCry CMS.

לעיתים קרובות מתכנתים כותבים תוכנה חדשה כך שתהיה תואמת לאחור, כלומר, התוכנה החדשה נועדה לקיים אינטראקציה טובה עם גרסאות ישנות יותר של התוכנה (באמצעות פרוטוקולים ישנים ופורמטים של קבצים) והגרסה העדכנית ביותר (באמצעות הפרוטוקולים והפורמטים העדכניים ביותר). לדוגמה, IBM z/OS תוכנן לעבוד כראוי עם 3 גרסאות עיקריות רצופות של מערכת ההפעלה הפועלת באותו סיספלקס. זה מאפשר לאנשים שמפעילים אשכול מחשבים בזמינות גבוהה לשמור על מרבית המחשבים פועלים בזמן שמכונה אחת בכל פעם מכובה, משודרגת וחוזרת לפעולה.Frank Kyne, Bert de Beer, Luis Martinez, Harriet Morril, Miha Petric, David Viguers, Suzi Wendler.
"System z Parallel Sysplex Best Practices".
2011.
p. 6.

לעיתים קרובות כותרות של מנות (packet headers) ופורמט קובץ כוללים מספר גרסה - לפעמים זהה למספר הגרסה של התוכנה שכתבה אותו; פעמים אחרות "מספר גרסת פרוטוקול" ללא תלות במספר גרסת התוכנה.

 הצהרה על שלב הפיתוח 
תוכנה בשלבים ניסיוניים (אלפא או בטא) משתמשת לעיתים קרובות באפס במיקום הראשון ("העיקרי") של הרצף כדי לקבוע את מעמדו. עם זאת, שיטה זו שימושית רק בשלבים המוקדמים, לא עבור מהדורות עתידיות עם תוכנות מבוססות שבהן מספר הגרסה כבר עבר את ה-0Preston-Werner, Tom (2013).
Semantic Versioning 2.0.0. Creative Commons.
Retrieved from https://semver.org/spec/v2.0.0.html.

מספר שיטות משמשות לציון הסטטוס של מהדורה חדשה יותר:
 סיומת אלפאנומרית היא שיטה נפוצה שאומצה על ידי שיטת גרסאות סמנטיות.Preston-Werner, Tom (2013).
Semantic Versioning 2.0.0. Creative Commons.
Retrieved from https://semver.org/spec/v2.0.0.html. בשיטה זו, נוסף לגרסאות מקף בתוספת כמה תווים אלפאנומריים כדי לציין את הסטטוס.
 סטטוס מספרי הוא שיטה המשתמשת במספרים כדי לציין את המצב כאילו הוא חלק מהרצף. בחירה טיפוסית היא המיקום השלישי עבור גרסאות בארבעה חלקים.
 Numeric 90+ היא שיטה נוספת שמשתמשת במספרים, נעשה שימוש במספר גדול במיקום האחרון, בדרך כלל 90 ומעלה. זה משמש בדרך כלל על ידי פרויקטים ישנים יותר בקוד פתוח כמו Fontconfig.

+השוואה בין מזהי שלב הפיתוח שלב פיתוח גרסאות סמנטיות סטטוס מספרי Numeric 90+ אלפא 1.2.0-a.1 1.2.0.1 1.1.90 בטא 1.2.0-b.2 1.2.1.2 1.1.93 מועמד למהדורה (RC) 1.2.0-rc.3 1.2.2.3 1.1.97 מהדורה 1.2.0 1.2.3.0 1.2.0 תיקונים לאחר ההפצה 1.2.5 1.2.3.5 1.2.5
שתי הצורות המספריות גרידא מסירות את המנגנון המיוחד הנדרש לטיפול בהשוואה של "alpha < beta < rc < no prefix" כפי שנמצא בגרסה סמנטית, במחיר הבהירות.

 רצפים גדלים 
ישנן שתי אסכולות בנוגע לאופן ההגדלה של מספרי גרסאות מספריים. רוב חבילות התוכנה החופשית והקוד הפתוח, כולל MediaWiki, מתייחסות לגרסאות כסדרה של מספרים בודדים, מופרדים על ידי נקודות, עם התקדמות כגון 1.7.0, 1.8.0, 1.8.1, 1.9.0, 1.10.0, 1.11.0, 1.11.1, 1.11.2 וכן הלאה.

מצד שני, חבילות תוכנה מסוימות מזהות מהדורות לפי מספרים עשרוניים: 1.7, 1.8, 1.81, 1.82, 1.9 וכו'. גרסאות עשרוניות היו נפוצות בשנות ה-80, למשל עם NetWare, DOS ו-Microsoft Windows, אך אפילו בשנות ה-2000 השתמשו בהן, למשל ב-Opera ו-Movable Type . בשיטה העשרונית, 1.81 היא הגרסה המינורית שלאחר 1.8, בעוד שחרור תחזוקה (כלומר תיקוני באגים בלבד) עשוי להיות מסומן בסיומת אלפביתית, כגון 1.81a או 1.81b.

שיטת המספור הסטנדרטית של GNU היא major.minor.revision, אך Emacs היא דוגמה בולטת לשימוש בשיטה אחרת שבה המספר הראשי (1) נשמט ונוספה גרסת אתר משתמש שהיא תמיד אפס בחבילות Emacs המקוריות אבל גדל על ידי מפיצים. באופן דומה, מספרי חבילות דביאן מקבלים קידומת "עידן" אופציונלי, המשמש כדי לאפשר את שינוי שיטת הגרסאות.Debian Policy Manual, 5.6.12 Version

 איפוס 
במקרים מסוימים, מפתחים עשויים להחליט לאפס את מספר הגרסה הראשית. זה משמש לפעמים לציון שלב פיתוח חדש שמתפרסם. לדוגמה, Minecraft Alpha רץ מגרסה 1.0.0 ל-1.2.6, וכאשר בטא שוחררה, היא איפסה את מספר הגרסה הראשית ורצה מ-1.0 ל-1.8. לאחר שהמשחק שוחרר במלואו, מספר הגרסה הראשית שוב התאפס ל-1.0.0.

 רצפים מפרידים 
בעת הדפסה, הרצפים עשויים להיות מופרדים באמצעות תווים. בחירת התווים והשימוש בהם משתנה בהתאם לשיטה. הרשימה הבאה מציגה דוגמאות היפותטיות של שיטות הפרדה לאותה מהדורה (הגרסה השלוש-עשרה של הרמה השלישית לגרסה הרביעית של הרמה השנייה לגרסה השנייה של הרמה הראשונה):
 שיטה עשויה להשתמש באותו תו בין כל הרצפים: 2.4.13, 2/4/13, 2-4-13
 הפרדה לא עקבית, כגון הפרדה בין רצפים מסוימים אך לא אחרים: 2.413
 בחירת התווים עשויה להיות לא עקבית בתוך אותו מזהה: 2.4_13 (לדוגמה, Minecraft Beta גדל מ-1.7 ל-1.7_01 ל-1.7.2)

 מספר רצפים 
לפעמים יש מספר רביעי, שלא מפורסם, שמציין את בניית התוכנה (כך במיקרוסופט). Adobe Flash הוא מקרה בולט שבו מספר גרסה של ארבעה חלקים מצוין בפומבי, כגון 10.1.53.64. חלק מהחברות כוללות גם את תאריך הבנייה. מספרי גרסה עשויים לכלול גם אותיות ותווים אחרים, כגון Lotus 1-2-3 Release 1a.

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

 תאריך שחרור 
ממוזער| מסך הפתיחה של Street Fighter EX המציג את מספר ההפצה בפורמט CalVer : "961219 USA"
פרויקטים רבים משתמשים בשיטת גרסאות מבוססת תאריך בשם Calendar Versioning (המכונה CalVer).

אובונטו היא דוגמה אחת לפרויקט המשתמש בגרסת לוח שנה; אובונטו 18.04, למשל, שוחרר באפריל 2018. יש לזה את היתרון של קישור בקלות ללוחות זמנים של פיתוח וזמני תמיכה. חלק ממשחקי הווידאו משתמשים גם בתאריך כגרסאות, למשל משחק הארקייד Street Fighter EX. בעת האתחול הוא מציג את מספר הגרסה כתאריך בתוספת קוד אזור, למשל 961219 ASIA.

בעת שימוש בתאריכים בניהול גרסאות, למשל, שמות קבצים, מקובל להשתמש בסכמת ISO 8601 YYYY-MM-DD, מכיוון שכך קל למיין בקלות מחרוזות בסדר עולה או יורד. לפעמים מושמטים המקפים. פרויקט Wine השתמש בעבר בסכמת גרסאות תאריך, שכללה שנה ואחריה חודש ואחריו יום השחרור; לדוגמה, "Wine 20040505". למיינקראפט היה עיצוב גרסה דומה, אך במקום זאת השתמש ב-DDHHMM, למשל: rd-132211, 13 הוא ה-13 במאי, ו-2211 הוא 22:11.

מספרי ה-build של Microsoft Office הם תאריך מקודד: שתי הספרות הראשונות מציינות את מספר החודשים שחלפו מינואר של השנה שבה התחיל הפרויקט (כאשר כל מהדורה עיקרית של Office היא פרויקט שונה), בעוד שתי הספרות האחרונות מציינות את היום באותו חודש. אז 3419 הוא היום ה-19 של החודש ה-34 לאחר חודש ינואר של השנה שבה הפרויקט התחיל.

דוגמאות נוספות המזהות גרסאות לפי שנה כוללות את Adobe Illustrator 88 ו-WordPerfect Office 2003. כאשר שנה משמשת לציון גרסה, זה בדרך כלל למטרות שיווק, וקיים גם מספר גרסה אמיתי. לדוגמה, Windows 95 הוא בגרסה פנימית של MS-DOS 7.00 ו-Windows 4.00; כמו כן, Windows 2000 בגרסה פנימית הוא NT 5.0.

 תרבות גיקית 
 הפצת SUSE Linux התחילה בגרסה 4.2, כמחווה ל-42, "התשובה לשאלה האולטימטיבית של החיים, היקום והכל" המוזכרת במדריך הטרמפיסט לגלקסיה של דאגלס אדמס.
 מפרט ה-Tagged Image File Format השתמש ב-42 כמספר גרסה פנימי מאז יצירתו. 

קישורים חיצוניים

הערות שוליים

קטגוריה:הנדסת תוכנה
קטגוריה:מערכות ניהול גרסאות
קטגוריה:דפים עם תרגומים שלא נסקרו