מה הם הכללים לגרסאות תוכנה וכיצד לצור גרסאות באופן נכון

פורסם על ידי

בקטגוריה

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

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

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

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

בדרך כלל ציון הגירסה יהיה מספרי לכן חייב להגדיל את המספר בכל שחרור של גירסה. מומלץ להתבסס על פי השיטה הסמנטית (SemVer) בה מבנה הגירסה כולל 3 ספרות בהתאם, לדוגמה: 1.3.7

המספר הראשוני מציין את הגירסה הראשית של התוכנה ואמור להתחיל ב-1.0.0 לתוכנה שלא נמצאת בשלב פיתוח או בטא.

המספר האמצעי יציין את הגירסה המשנית של התוכנה ומיועד עבור הוספת תכונות

והספרה האחרונה היא עבור תיקונים קטנים ובאגים

גירסת פיתוח או גירסת אלפא

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

הספרה הראשונית 0 תציין פיתוח ראשוני של היישום, לדוגמה: גירסה 0.3.1

דרך נוספת לציין זאת היא באמצעות הוספת המילה alpha אל הגירסה: 1.0.0-alpha

גירסת בטא

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

כדי לציין גירסת בטא לתוכנה נהוג להוסיף את המילה beta אל הגירסה: 1.0.0-beta

דרכים אחרות של גרסאות

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

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

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

גירסת פיתוח שונה מהשם השיווקי

שימו לב שניתן להפריד את שם גירסת הפיתוח הפנימית לזו השיווקית, דוגמה כזאת נוכל לראות אצל מיקרוסופט עם מערכת הפעלה ווינדוס, בהתחלה ווינדוס התבססה על מתן גרסה רגילה, Windows 1.0, 1.1, 2.0 וכן הלאה… עד לווינדוס 95 ששוחרר בשנת 1995 ועל כך שמו השיווקי אך הוא למעשה ווינדוס 4.0 וכך גם שאר גרסאות הווינדוס: Windows 98 (4.10), Windows 2000 (5.0), שנת ההשקה נבחרה כשם השיווקי של גירסת הווינדוס.

בהמשך היה את Windows ME (4.9), Windows XP (5.1) ו-Windows Vista (6.0) ולאחר מכן שוב בחרה מיקרוסופט לשים מספרי גרסאות אבל שימו לב, אלו הם רק גרסאות שנועדו כשם שיווקי, גרסאות הפיתוח הם שונות, לדוגמה: Windows 7 היא גירסה 6.1 של ווינדוס, Windows 8 היא גירסה 6.2.

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

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

נכתב על ידי:

יוסי אהרון

יוסי אהרון


כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *


דילוג לתוכן