Request: permanent stable updates policy exception for GIMP _within_ major releases #3511

New issue

Closed

opened 2025-11-21 11:24:30 +00:00 by nphilipp · 10 comments

nphilipp commented

2025-11-21 11:24:30 +00:00

Hi!

I’d like to request a permanent exception to the stable release update policy for GIMP within a major release (e.g. 3.0.z ⇒ 3.2.0, not 3.y.z ⇒ 4.0.0), for these reasons:

Upstream GIMP seems to be serious about a quicker cadence of minor releases, RC1 of 3.2.0 was released a couple of days ago. I would like to update to the real 3.2.0 in stable Fedora releases when it’s available, on top of feature enhancements – which is why I’m here 😉 – it contains many bug fixes.
Historically (and also this time), when a new version is in the works, upstream concentrates efforts on the upcoming release and bug fixes only rarely make it into the old, stable branches. When a new release was made official, next to no fixes made it into old branches.
I don’t have the capacity to identify and backport fixes from say the gimp-3-2 branch to gimp-3-0, not the least because in many cases I can’t even reproduce bugs users are experiencing.
Upstream has a good track record of maintaining compatibility between minor releases. In cases compatibility had to be broken, this was well documented and isolated. I understand that with doing such an upgrade mid-release comes the responsibility to assess whether or not compatibility with 3rd party plug-ins and extensions is affected, and fix things in a side-tag before they reach unsuspecting users or become a problem of their maintainers.
For illustration, with 3.2 the plug-in API was extended but not changed incompatibly. I have built pre-releases of GIMP 3.2 in COPR and, for me, they worked well with 3rd party plug-ins available in Fedora.
Also historically, many users asked me to include even pre-releases of GIMP, indicating to me that they would prefer potentially changed workflows to “being stuck” with an old version. NB: this ticket is not about having pre-releases in stable Fedora, that’s what COPR is for.

Hi! I’d like to request a permanent exception to the stable release update policy for GIMP *within* a major release (e.g. 3.0.z ⇒ 3.2.0, not 3.y.z ⇒ 4.0.0), for these reasons: - Upstream GIMP seems to be serious about a quicker cadence of minor releases, RC1 of 3.2.0 was released a couple of days ago. I would like to update to the real 3.2.0 in stable Fedora releases when it’s available, on top of feature enhancements – which is why I’m here :wink: – it contains many bug fixes. - Historically (and also this time), when a new version is in the works, upstream concentrates efforts on the upcoming release and bug fixes only rarely make it into the old, stable branches. When a new release was made official, next to no fixes made it into old branches. - I don’t have the capacity to identify and backport fixes from say the gimp-3-2 branch to gimp-3-0, not the least because in many cases I can’t even reproduce bugs users are experiencing. - Upstream has a good track record of maintaining compatibility between minor releases. In cases compatibility had to be broken, this was well documented and isolated. I understand that with doing such an upgrade mid-release comes the responsibility to assess whether or not compatibility with 3rd party plug-ins and extensions is affected, and fix things in a side-tag before they reach unsuspecting users or become a problem of their maintainers. - For illustration, with 3.2 the plug-in API [was extended](https://www.gimp.org/news/2025/11/17/gimp-3-2-RC1-released/#api) but not changed incompatibly. I have built pre-releases of GIMP 3.2 in COPR and, for me, they worked well with 3rd party plug-ins available in Fedora. - Also historically, many users asked me to include even pre-releases of GIMP, indicating to me that they would prefer potentially changed workflows to “being stuck” with an old version. NB: this ticket is not about having pre-releases in stable Fedora, that’s what COPR is for.