Create next milestones after a release is prepared

[Ocramius]

Feature Request

See doctrine/automatic-releases#26

After a release is done, we want to implicitly generate new milestones.

Given following milestones:
  | name |
  | 1.0.0 |
When milestone 1.0.0 is closed
Then following milestones should exist:
  | name |
  | 1.0.1 |
  | 1.1.0 |
  | 2.0.0 |

This should probably be done as a new command to be added to the automatic-release workflow example.

Note: the command must gracefully ignore pre-existing milestones with same names, and duplicate milestone names must never be possible!

Q	A
New Feature	yes
RFC	no
BC Break	no

[geerteltink]

I was wondering, should the 2.0.0 milestone be created even when it's not needed yet? How about we check if we check to a new milestone created event and create a release branch from the current default branch for it (if it doesn't exist). This way we don't need to sync everything to a possible 2.0.x branch if there is no need for it.

[Ocramius]

IMO it doesn't hurt to always create the next major milestone: sync-up is a relatively painless process, and the next major branch can be deleted if needed

[geerteltink]

Which one would be the default branch if 1.2.x and 2.0.x are created? 1.2.x?

[Ocramius]

This is only about creating the new milestone, not the branch.

The tool does not implicitly create a new major branch, or else it would always set it as the default branch too (messy).