Gitlab milestones

This document describes how the GIMP project uses milestones in the GNOME gitlab issue tracker

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.