Document the release process

[morozov]

As discussed with @jwage, below is the cheat sheet I've been following for the last few releases.

Minor release (e.g. 2.9.0)

1. Prepare release notes on GitHub as a draft.
2. Make sure the changes between the tags correspond to the issues in the milestone.
3. Create 2.9 from master (which currently represents 2.9.0-DEV).
4. In the 2.9 branch, change Version from 2.9.0-DEV to 2.9.0.
5. Commit as "Release 2.9.0".
6. Tag as "Release 2.9.0", copy prepared release notes into the tag description. Use --cleanup=whitespace to preserve the lines starting with #.
7. Change Version from 2.9.0 to 2.9.1-DEV.
8. Commit as "Bump version to 2.9.1-DEV".
9. Push the branch to GitHub.
10. Add the new branch to Scrutinizer.
11. Update settings on ContinuousPHP, if needed (there are branch-specific configuration bits).
12. Wait for the build on Travis.
13. Push the tag on GitHub.
14. Publish the release on GitHub.
15. Create a local branch 2.10.0-DEV branch from master.
16. Change Version from 2.9.0-DEV to 2.10.0-DEV.
17. Make needed changes to .doctrine-project.json.
18. Update README.md.
19. Commit as "Bump version to 2.10.0-DEV".
20. Submit a pull request 2.10.0-DEV → master.
21. Tweet.
22. Close the 2.9.0 milestone on GitHub, create 2.10.0.

Patch release (e.g. 2.9.1)

1. Prepare release notes on GitHub as a draft.
2. Make sure the changes between the tags correspond to the issues in the milestone.
3. In the 2.9.x branch, change Version from 2.9.1-DEV to 2.9.1.
4. Commit as "Release 2.9.1".
5. Tag as "Release 2.9.1", copy prepared release notes into the tag description:

   $ git tag -s 2.9.1 -F ~/Release\ 2.9.1.md --cleanup=whitespace

6. Push the branch on GitHub.
7. Wait for the build on Travis.
8. Push the tag on GitHub.
9. Publish the release on GitHub.
10. Change Version from 2.9.1 to 2.9.2-DEV. Even if no more patch releases are planned. it's better to keep the branch in the state that can accept new unplanned commits.
11. Commit as "Bump version to 2.9.2-DEV".
12. Tweet.
13. Close the 2.9.1 milestone on GitHub, create 2.9.2, if planned.

The above can be used as a starter for a documentation article and release process automation in the future. Comments are welcome.

[Ocramius]

Maybe to be integrated in doctrine/doctrine-website#262?

[morozov]

Definitely. I didn't know it exists.

[greg0ire]

In case you're interested, what I do on Sonata is push the branch on my fork, wait for the build, let people approve the changelog and atomically (as in push --atomic) push both the branch and the tag, which closes the PR as a side effect.

That way no commit is pushed without being reviewed and approved. Also we are required to sign tags, maybe it would be worth mentioning if that is what you do?

[Ocramius]

Also we are required to sign tags, maybe it would be worth mentioning if that is what you do?

https://github.com/doctrine/doctrine-website/pull/262/files#diff-3d5f4cc6a26dc9ccf134b1dfe33e38f5R208

Meanwhile, closing as duplicate here.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.