לא באמת משנה אם מדובר בספרייה או באפליקציה גדולה. סכימת גרסאות סמנטית עובדת מצוין עבור אפליקציה גדולה. היא יכולה אפילו לשמש לאוסף של אפליקציות המקובצות לפלטפורמה, אך כאן זה הופך להיות די קשה להתמודדות.
השאלה העיקרית היא האם אתה הולך במסלול של deprecation (הפסקת שימוש) נתמך במהדורה אחת, ורק הסרה שלו במהדורה ראשית הבאה. קיום פונקציונליות שהופסקה אך עדיין נתמכת, יכול לקחת לא מעט מאמץ. כאשר אתה עומד לבצע שינויים במודל הנתונים השמור שלך, הפסקת שימוש יכולה לעיתים קרובות להפוך לבלתי אפשרית. אם זה קורה, אתה אפילו לא יכול לעשות גרסה מינורית עם פונקציונליות שהופסקה, ואתה קופץ מיד לגרסה ראשית הבאה. זה החלק שבו אפליקציות גדולות בדרך כלל נתקלות בבעיות. אתה עובר מ-3.0.0 ל-3.0.1 ל-4.0.0 מכיוון שאינך יכול לספק תאימות לאחור. אם יש לך לעיתים קרובות שינויים שוברים (breaking changes), היצמדות ל-semver מוסיפה מעט ערך.
עם זאת. אני הרבה יותר מעדיף את המבנה הזה מכיוון שהוא מתקשר בצורה ברורה יותר למפתחים שיהיו שינויים שוברים. סכימת YYYY.N לא אומרת לי כלום כמפתח, ולא כלום כמנהל מערכת.
לכן השאלה היא, מה אתה רוצה לתקשר עם הגרסה? אם אתה רוצה לעשות 6 מהדורות תכונה (feature releases) (שיכולות להיות שוברות או לא), ובכל מהדורה שישית תהיה תמיכה ארוכה יותר עם תיקונים (patches); ואתה לא רוצה לתת גרסאות למהדורות תיקון. אז X.Y היא סכימה מתאימה, כאשר Y=0 היא זו הנתמכת לאורך זמן. X יהיה פשוט מספר. הבעיה היא כאשר X הוא השנה, אז Y משויך במהירות לחודש. אז מהדורות נתמכות לאורך זמן חדשות ישוחררו בינואר? אני תמיד צריך לבדוק איזו גרסת אובונטו היא LTS, מה שמעצבן אותי.
אז מה אם Discourse פשוט ימשיך עם הגרסה הראשית הנוכחית. הגרסה הנתמכת לאורך זמן הבאה נקראת 4.0; ואז נקבל 4.1 עד 4.5 כמהדורות תכונה; ואחריהן 5.0 שהיא החדשה ביותר הנתמכת לאורך זמן.
אז גם לא יהיה לך את הרגע המביך הזה שבו מהדורה מתעכבת בגלל בעיה גדולה.
אתה יכול אופציונלית להוסיף מספר “תיקון” (patch) אם אתה מתכנן לשחרר תיקונים במפורש (במקום שיהיו תיקונים מתגלגלים). “אבל אז יש לך x.y.z שזה semver”. ובכן, לא, זה נראה כמו semver, אבל זה לא. כל מהדורת “מינור” חדשה יכולה להיות שוברת. לכן אני מציע פשוט להיצמד לסכימת גרסה X.Y עם Y=0 → LTS.
מחרוזת הגרסה בצד. אני כן אוהב את תוכנית השחרור החדשה.