# v8 release process retrospective Feel free to add your thoughts here! We'll organize it later. - Next time we should more aggressively prioritize getting as many PRs as possible merged or closed before new branch creation - If we're doing this many code moves, we may want to entirely "lock" master next time (in the sense of not allowing any changes to *any* package). If anybody is checking in to *any* package in master, that means it must continue being buildable at all times, which forces giant changes such as OUFR rename/deletion to be done in one giant commit. (or very briefly turn off squash merge policy, which we might do) - Try to avoid letting nonsense internal jargon (like "snap" referring to a 2-week period) get into public communication :laughing: - (Not straightly related to the release process) When we plan for v9 release, we should finalize and communicate to partner a process for deprecation removals. - Moving "next" components to current is not necessarily easy! It's basically like a mini upgrade within our own repo. (This time we got hung up by having to pick up API changes in within-repo consuming packages, and by some issues revealed by the additional test coverage for v-current.) - We should potentially run ssr-tests against vnext - Keeping the communications (e.g. dates, change of plans, contribution proccess guidance) update to date is challenging - Scripting should be a prioritization and should happen first and as part of the planning.