mirror of https://gitee.com/openkylin/glib2.0.git
67 lines
3.1 KiB
Markdown
67 lines
3.1 KiB
Markdown
|
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](./releasing.md), 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.
|