mirror of https://github.com/GNOME/gimp.git
72 lines
2.9 KiB
Plaintext
72 lines
2.9 KiB
Plaintext
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.
|