docs/roadmap.md

   1 Roadmap
   2 ===
   3
   4 The roadmap for development of GLib in upcoming releases is tracked in GitLab,
   5 using its [milestones feature](https://gitlab.gnome.org/GNOME/glib/-/milestones).
   6 Look on the upcoming milestones to see what features and fixes are planned for
   7 each release.
   8
   9 An issue being assigned to a milestone is no guarantee that it will actually be
  10 fixed in time for that milestone. Milestones are a rough prioritisation system
  11 for work, but GLib is a volunteer project with no fixed resources, so no
  12 guarantees can be given.
  13
  14 All releases are time-based rather than feature-based, as the development and
  15 stable branches of GLib should always be in a releasable state. Sometimes, at
  16 the discretion of the maintainers, a release may be held for a week or so in
  17 order to allow a particular merge request to land so that it can be made
  18 available to distributions or testers more rapidly.
  19
  20 When [making a release](./releasing.md), all remaining issues and merge requests
  21 allocated to the milestone for that release should be fixed (potentially
  22 delaying the release), or rescheduled to a different release, based on the
  23 maintainers’ assessment.
  24
  25 Unstable release planning
  26 ---
  27
  28 At the start of a development cycle, milestones are created for each release in
  29 the cycle according to the [GNOME release
  30 schedule](https://wiki.gnome.org/Schedule). GLib roughly follows the GNOME
  31 release schedule, but makes its releases one or two weeks ahead of each
  32 corresponding GNOME release. This allows other GNOME modules to depend on the
  33 correct GLib version for new APIs. GLib does not follow the GNOME module
  34 versioning scheme.
  35
  36 As the milestones are created, maintainers will assign issues to them, based on
  37 what they think is possible to achieve for each milestone given the amount of
  38 developer time available before the release.
  39
  40 Issues affecting a lot of users (such as common crashes), and new features which
  41 maintainers think will have a wide benefit are prioritised.
  42
  43 As a development cycle progresses, some of the releases are timed to coincide
  44 with [GNOME’s API/feature, string and hard code
  45 freezes](https://wiki.gnome.org/ReleasePlanning/Freezes). Issues which add API
  46 and features are scheduled for the earlier micro releases in a development
  47 cycle, followed by issues which add or change translatable strings, followed by
  48 smaller bug fixes, documentation and unit test updates.
  49
  50 Stable release planning
  51 ---
  52
  53 Stable micro releases are scheduled at a cadence picked by maintainers,
  54 depending on the rate at which bugs are being found in that stable branch. More
  55 bugs leads to a more frequent release cadence.
  56
  57 Historically, the rate of releases on each stable branch has decreased inversely
  58 proportionally to the time since the initial release of that branch.
  59
  60 There is no limit on the number of micro releases in a stable release series.
  61 Typically there will be around 6. Micro releases stop once there are no more
  62 bugs found in a stable series, or once a new stable series supercedes it.
  63
  64 The milestone for the next micro release in a stable series is created when the
  65 previous micro release is made, such that only one stable micro release is
  66 scheduled at any time.