We're doing release early, release often (RERO) at the moment.
RERO releasing stages:
Alpha 1, 2, n:
- One month starting at 1st till last day of the month
- 20 Days of merging features/bigger changes
- Remaining days fixes only or obvious non breaking stuff (this can be a feature in exceptional cases)
Beta 1, 2, n:
- At least one month starting at 1st till last day of the month.
- Several betas for fast feedback from users during that month. At least two or more
- API freeze, features/changes still possible if not affecting API (unless it's a fix)
Release candidate (RC):
- One month depending on how the beta stage went
- several RC for fast feedback from users. At least two or more
- Branching for final is done after RC stage or upon agreement from core developers
- Feature freeze, fixes only.
- No merge window as there are no features
- Final bump is pushed as into the branch for that version (e.g. "Jarvis" branch")
- Depending on amount and/or severity of fixes, discuss point releases. Rinse and repeat the point release process. Keep Branch open for x months of backporting and then close it for good.
- This branch will get backports from master, for problems that arise. In case you want something backported tag it "backport needed". Once the PR is opened for backport tag the initial PR to master as "backport done".
- Bump master branch to next version and restart from alpha1
Features can be merged from the 1-20 of the month. Only for when in alpha or in exceptional cases in beta.
- Merge window is 20 days. To make it more abstract in time, it ends at midnight GMT of the 20th day
- Remaining days will be fixes only for stabilising towards an "official" month release
- Multiple devs (internal/external) need to review code and +1 for inclusion (one line fixes are ok of course)
- The +1 should be more strict during beta/RC