התקנת ה-Discourse שלי יצאה מכלל שימוש (3.2.0.beta4-dev) ואני צריך לשדרג ל-3.5. אני חושש להפריע לדברים ולהשתמש בכמה תוספים/אינטגרציות שלא רציתי לשנות (WP Discourse, כניסה דרך Wordpress עם מידע חברות ותוסף Category Lockdown) והיו לי בעיות בשדרוג ידני בעבר.
מהי הגישה הטובה ביותר לביצוע השדרוג? האם עלי לבצע סוג של שדרוג חלקי לגרסה אחרת תחילה? האם ישנם מכשולים שעלי להיות מודע אליהם?
פרוס פורום בדיקה. מעולם לא פיצלתי דבר
If you want to be safest, you’ll spin up a new server, Move a Discourse site to another VPS with rsync (I’d skip the database files), and restore a backup.
I’m pretty sure that you’ll need to PostgreSQL 15 update.
There should be no issues with WP Discourse. You can check Discourse Category Lockdown.
There’s a pretty good chance you can just follow the PG 15 upgrade and everything will be fine, but you asked about “best practices”.
This has some good side-effects, of ensuring you have a recent backup and you have a safe copy of that backup. You do need to do those things, however you approach your upgrade.
I get the impression it would be good practice to comment out all your plugins too, but it would be good for someone to confirm that.
Yeah. Actually, knowing that you can spin up a new server and restore a backup. I had to do this once recently when one of my server’s had a SSD die. I wished that I had actually practiced (though, as it turned out, though I hadn’t explicitly practiced, having gone through the process hundreds of times was enough and it all went as planned).
There is no downside, especially since a bunch of plugins got moved to core and there could be something old that’s broken. After the thing is in working order, you can go about restoring whatever plugins you notice are missing.
שיטת עבודה מומלצת? שמור רשימת תיוג איפשהו, אתה יכול להוסיף אחת בממשק ה-UI של ה-admin ב-update על ידי הוספת ה-CSS הזה לנושא שלך (../admin/customize/themes/ edit css) אם מתישהו לך או למישהו אחר יהיה הרעיון לעדכן מהר מדי:
.admin-contents.update .d-nav-submenu::before {content:“רשימת תיוג עדכון” : גיבוי בוצע?\" ; “הודעת מטא אחרונה נקראה? ; באגים חשובים של החודש האחרון מ-Meta נבדקו? תאימות תוספים חיוניים נבדקה? גרסת תאימות Postgres/Redis נבדקה? תזמון נכון לעדכון נבדק? זמינות כוח אדם לפתרון בעיות במקרה של כשל בעדכון נבדקה?” }
רשימות תיוג הן רעיון טוב. אני אישית, כשאני שוקל שדרוג, מחכה לגרסה, מחכה כמה ימים, מחכה ליום חול, קורא את קטגוריות הבאגים והתמיכה כדי לראות אילו בעיות אנשים חווים. ומחכה שהבעיות הללו, אם ישנן, יתוקנו.
You are on stable presumably? Otherwise this strategy wouldn’t help with continuous integration …
No, I’m on tests-passed. It’s true that my delay of a few days will allow some stray further commits to be added to the repo, but at the same time it allows some mistakes to have been corrected. Almost all commits, of course, are not problematic, so I think it’s a good tradeoff, but opinions may differ.
ישנה נחיל של שדרוגים מיד לאחר בטא חדשה, כך שגם במבחנים שעברו, כמה ימים לאחר שדרוג הוא זמן טוב לשדרוג. או, אולי אנו חולקים את אותה לוגיקה פגומה!
I remain unconvinced without a supporting graph. 
אני חושב שהיית, אה, רואה משהו כמו אחוז ה-commits שקשורים לבאגים (לא בטוח איך לכמת את זה - אולי פשוט לספור את אלה עם "FIX" ב-commit?) עבור 5 הימים שלאחר שחרור בהשוואה לאחוז עבור שאר הזמן.