Setup automatic release workflow

[greg0ire]

I created this PR with the UI (that's why no fork is in use here). It naturally picked 2.11.x, I didn't have the option to pick anything else, so this must be the correct branch for this.

[morozov]

One caveat here is that for 2.x we still use the release process described in #3406 which requires manually bumping the version in the source code before and after the release.

We need to make sure this workflow doesn't contradict the existing one and come up with the proper instructions that take the new automation into account. E.g. do not close the milestone until the version is bumped.

Worst case, we’ll have to wait until 2.x is no longer supported.

[greg0ire]

Here is how I think it could look like, I'm unsure about the branch creation though, will have to check if the tool creates them for us.

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. Push the branch on GitHub.
7. Wait for the build.
8. Tag as "Release 2.9.0", copy prepared release notes into the tag description. Use --cleanup=whitespace to preserve the lines starting with # Close the milestone.
9. Change Version from 2.9.0 to 2.9.1-DEV.
10. Commit as "Bump version to 2.9.1-DEV".
11. Push the branch to GitHub.
12. Add the new branch to Scrutinizer.
13. Update settings on ContinuousPHP, if needed (there are branch-specific configuration bits).
14. Wait for the build on Travis.
15. Push the tag on GitHub.
16. Publish the release on GitHub.
17. Create a local branch 2.10.0-DEV 2.10.x branch from master.
18. Change Version from 2.9.0-DEV to 2.10.0-DEV.
19. Make needed changes to .doctrine-project.json.
20. Update README.md.
21. Commit as "Bump version to 2.10.0-DEV".
22. Submit a pull request 2.10.0-DEV → master.
23. Tweet.
24. 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. Close the milestone
10. Change Version from 2.9.1 to 2.9.2-DEV, if more patch releases are planned in the series.
11. Commit as "Bump version to 2.9.2-DEV".
12. Tweet.
13. Create 2.9.2, if planned.

[morozov]

Looks reasonable. We could validate the workflow with 2.10.4.

[greg0ire]

I read a bit more, it also creates new milestones, so this can be simplified further, I will edit my comment.

[morozov]

What if we don't need a new minor/patch milestone?

[greg0ire]

Good question, I asked here: https://discourse.laminas.dev/t/laminas-automatic-releases-how-do-you-stop-the-milestones/1824

[morozov]

This needs a rebase to fix the build failures.

[greg0ire]

I would expect it not to, but ok it does seem to require it.