gitlab-milestones.txt
-----------------------

This document describes how the GIMP project uses milestones in the
GNOME gitlab issue tracker found at:
https://gitlab.gnome.org/GNOME/gimp


Stable milestones
-----------------

We will create one milestone per micro-point release, as well as one per
minor-point release. For instance, if GIMP 2.10 is the stable release
branch, we will have a `2.10.32` milestone as well as a `2.10`
milestone.

Add reports to the next micro-point milestone when you expect to
fix/implement the bug or feature in this time frame; add it to the
minor-point milestone if you expect (or hope) to fix/implement in one of
the stable release yet doubt if will happen in the next release.

When planifying a new release, a maintainer must create the next
micro-point milestone shortly before releasing and start moving any
still opened report which could not be solved to this new milestone. For
instance before releasing 2.10.32, create the milestone `2.10.34`, then
go through all opened reports in `2.10.32` and move them to `2.10.34`
(unless someone expects to fix some at the last minute). When closing a
milestone, it must not contain any opened report.

The `2.10.32` milestone will be closed when GIMP 2.10.32 was released.
The `2.10` milestone will be closed only when no point releases are
expected in the 2.10 branch anymore.

Reports that are fixed in the stable branch should have the relevant
stable milestone set. Usually such a fix is done in the development
branch and then cherry-picked to the stable branch.


Next stable milestone
---------------------

Similar rules apply to the next stable branch, for instance `3.0`
minor-point milestone and individual `2.99.10` micro-point milestones.

Note that any new feature must always be implemented in the next
stable milestones first. Indeed we don't want regressions (new features
popping in a 2.10 version then disappearing in 3.0). Yet they may be
backported later if some developers are willing to work on it. When this
happen, the report's milestone may be updated to the first version which
gets the feature.

If you fix a bug or implement a feature request for a release, then
please make sure that the milestone is set accordingly. This allows us
to make a list of changes by looking at the resolved bugs on the
milestone.


Future milestone
----------------

The bugs/enhancement requests on the `Future` milestone are things that
the GIMP project eventually wants to include in a future version, but in
what version is not yet decided.

Note that "decision" is a fluid notion. Indeed it mostly means that
someone cared enough for it to implement it properly. Therefore all it
takes is one of the developers making a point to work on a feature in a
given time frame.
Within such logic, the `Future` milestone is really more of a way to
tell that an improvement is a good idea, hence we'd be happy to have it,
yet nobody took on the task.
