Most milestones are tied to releases and are named using the three-component package version of the release, e.g. 3.14.0.
When we assign milestones, however, we don't necessarily know what the next release will be. For example, if the latest release was 3.14.0,
the next release might be 3.14.1 or 3.15.0, depending on whether we end up with new features or only bug fixes.
We handle that by assuming that the next release will be a minor upgrade - 3.15.0 in the preceding example. When we are ready to release, there are two possibilities...
-
If the milestone contains completed features or enhancements, then we would stick with version
3.15.0... a MINOR upgrade. -
If there are no new features or enhancements, then we rename the milestone... to
3.14.1in this case.
Normally, we only release when one or more features are complete, so the first case is expected to be the most frequent.
In addition to release milestones, we may set up other milestones from time to time, as a way of categorizing certain kinds of changes. For example a Future milestone could hold ideas and features we want to consider at some future time, without knowing in which release it might be done. Milestones of this type should not be given a version number as a name.