---
# System prepended metadata

title: v8 release process retrospective

---

# 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.