[glib: 1/2] docs: Add a roadmap policy

[Philip Withnall <pwithnall src gnome org>]

commit 50877bb2d155b9cd2ff3704082837a2b5c8d94cb
Author: Philip Withnall <pwithnall endlessos org>
Date:   Sun May 22 17:02:00 2022 +0100

    docs: Add a roadmap policy
    
    This describes how releases are planned and scheduled, and where users
    of GLib can look to see what the current (loose) roadmap is.
    
    Signed-off-by: Philip Withnall <pwithnall endlessos org>

 docs/roadmap.md | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)
---
diff --git a/docs/roadmap.md b/docs/roadmap.md
new file mode 100644
index 0000000000..1e3253bfea
--- /dev/null
+++ b/docs/roadmap.md
@@ -0,0 +1,65 @@
+Roadmap
+===
+
+The roadmap for development of GLib in upcoming releases is tracked in GitLab,
+using its [milestones feature](https://gitlab.gnome.org/GNOME/glib/-/milestones).
+Look on the upcoming milestones to see what features and fixes are planned for
+each release.
+
+An issue being assigned to a milestone is no guarantee that it will actually be
+fixed in time for that milestone. Milestones are a rough prioritisation system
+for work, but GLib is a volunteer project with no fixed resources, so no
+guarantees can be given.
+
+All releases are time-based rather than feature-based, as the development and
+stable branches of GLib should always be in a releasable state. Sometimes, at
+the discretion of the maintainers, a release may be held for a week or so in
+order to allow a particular merge request to land so that it can be made
+available to distributions or testers more rapidly.
+
+When making a release, all remaining issues and merge requests allocated to the
+milestone for that release should be fixed (potentially delaying the release),
+or rescheduled to a different release, based on the maintainers’ assessment.
+
+Unstable release planning
+---
+
+At the start of a development cycle, milestones are created for each release in
+the cycle according to the [GNOME release
+schedule](https://wiki.gnome.org/Schedule). GLib roughly follows the GNOME
+release schedule, but makes its releases one or two weeks ahead of each
+corresponding GNOME release. This allows other GNOME modules to depend on the
+correct GLib version for new APIs. GLib does not follow the GNOME module
+versioning scheme.
+
+As the milestones are created, maintainers will assign issues to them, based on
+what they think is possible to achieve for each milestone given the amount of
+developer time available before the release.
+
+Issues affecting a lot of users (such as common crashes), and new features which
+maintainers think will have a wide benefit are prioritised.
+
+As a development cycle progresses, some of the releases are timed to coincide
+with [GNOME’s API/feature, string and hard code
+freezes](https://wiki.gnome.org/ReleasePlanning/Freezes). Issues which add API
+and features are scheduled for the earlier micro releases in a development
+cycle, followed by issues which add or change translatable strings, followed by
+smaller bug fixes, documentation and unit test updates.
+
+Stable release planning
+---
+
+Stable micro releases are scheduled at a cadence picked by maintainers,
+depending on the rate at which bugs are being found in that stable branch. More
+bugs leads to a more frequent release cadence.
+
+Historically, the rate of releases on each stable branch has decreased inversely
+proportionally to the time since the initial release of that branch.
+
+There is no limit on the number of micro releases in a stable release series.
+Typically there will be around 6. Micro releases stop once there are no more
+bugs found in a stable series, or once a new stable series supercedes it.
+
+The milestone for the next micro release in a stable series is created when the
+previous micro release is made, such that only one stable micro release is
+scheduled at any time.