-
Notifications
You must be signed in to change notification settings - Fork 1.1k
ReleasePlanning
(This is at present a statement of how we think we will do this. To be altered once it has met with reality.)
The aim of planning releases is to have some degree of predictability to when bugs will be fixed and features added. For example, so we can have some confidence in making statements like "this will be fixed in the next patch release, which is due in a week's time"; or, "your PR should be included in the next feature release, which is in three weeks".
It also gives us a bit of framing to be able to discuss what issues to go after, and which features to .
We will use milestones to track what is due to be included in a release. The contents of a milestone can be either issues we intend to fix, or PRs that we intend to have merged. Ultimately, we will report on the PRs, rather than the issues, but we do need to track which bugs we intend to have fixed.
The milestone reflects the current plan, up to the point that the release is actually made. So we can add or remove things, to reflect changing priorities. For example, if someone contributes a PR, we will usually want to include it in the next (patch or feature) release, so we may add it to the milestone.
We will have two kinds of release: patch releases (given a patch version bump), and feature releases (given a minor version bump). Major releases are out of scope for these instructions.
Tentatively, patch releases happen every two weeks; feature releases every two months.
There is a patch release every two weeks. This release will contain any changes that
- are not new features; and,
- are backward-compatible
We can nominate issues to be fixed in the next patch release at any time. We should be careful that there is a realistic prospect of being able to fix the issue in time, of course.
Every two months, the release is a feature release. This contains anything that would be in a patch release, and any backward-compatible features that were marked to be included. Backward-_in_compatible changes would indicate a major release, which will need to be handled as an exception to these instructions.