Jehan Pages who is the lead developer and maintainer of GIMP made an announcement on Patreon yesterday. GIMP 3.0 is tentatively scheduled for release in May 2024. The plan is to announce the release at the next Libre Graphics Meeting conference in France. There is a page that details the roadmap.
So let’s talk about the paint points: stopping development of new features while trying to get non-destructive editing into 3.0, making more API changes, fixing a load of bugs.
Below goes edited transcript of the video.
Feature freeze
Right off the bat, the proposal is to start with a feature freeze in the middle of December. A feature freeze basically means this. Every new line of code that you write has the potential to introduce a new bug or even many bugs. So if you expect to release software that doesn’t crash much and doesn’t throw too many error messages at users, at some point you have to stop writing new features and focus on fixing bugs.
Today is the 22nd of November, the tentative release date is around May 9 of the next year, that makes nearly 5 months between now and the release and closer to 4 months between the feature freeze and the release.
There are three major topics here to unpack.
Non-destructive editing
First of all, development of new features has been decelerating over the past few years, with focus shifted towards completing the port to GTK3. But most recently CmykStudent resumed his Google Summer of Code project where he hacked on non-destructive filters attached to layers.
The interface you see here (the bottom part of the screenshot above) is pretty much a slight evolution of the non-destructive embryo that has already been there for many years. The real deal will look nothing like this. It’s just that the public branch doesn’t yet have the latest work that CmykStudent demonstrated on Twitter recently:
If you have a look at the full proposal on the GIMP developers website, you’ll see that it should be possible to stack effects and edit their masks. They thought about a lot of things, which is great.
But it also looks like completing the full proposal is not something you can do in 3 to 4 weeks before the feature freeze. So there is a strong possibility that we will either end up with a basic implementation for 3.0 and then see more in the next updates. Or the developers will postpone this patch till version 3.0.2 that is expected to be released soon after 3.0.
In other words, the worst case scenario here is that GIMP 3.0 loses that bit of numerology where a release with a fancy number gets a fancy new feature. Personally, I’m okay with that idea. We’ve been waiting for non-destructive editing for frigging 23 years since the beginning of the work on GEGL, two or three more months — it’s not too bad. But judging by the response on Twitter the first possibility is more likely to happen which means a basic implementation in 3.0:
Yeah, the GUI can be improved iteratively (as long as it's not *horrible*; i.e. not perfect yet in releasable state). Though the file format side will have to be stable (this can't change version after version for compatibility).
— @ZeMarmot@fosstodon.org (@zemarmot) November 21, 2023
I think it is feasible for @CmykStudent ! :-)
So let’s wait and see.
API changes
The second important topic is API changes. This is something I’m actually more concerned about. Historically, this has been the number one reason for long, long development cycles in GIMP. Jehan specifically says:
I am not including API features on purpose in the freeze, because I think an additional month for the last little tweaks may be worth it
One of the ongoing changes here is the new API that helps make GIMP more omnivore in terms of color spaces and color models. So instead of functions like GimpRGB and GimpCMYK built right inside GIMP you get an exposure to all the color models available in GEGL and babl, and that’s a lot.
babl supports the entire CIE family of color models — LAB, LCH, YUV, XYZ — as well as newer things like OKlab. Not to mention CMYK, HSV, HSL, and friends. Most recently, GEGL itself got functions for getting and setting CMYK colors.
My primary concern here is that getting and setting colors is something that happens in GIMP all the time, even if you don’t see it in the user interface. Just searching for ‘GimpRGB’ reveals almost 800 instances in the part related to user interface and over 400 instances in the backend code. That’s a lot.
Which means that attempting to complete this API rewrite in time for the release will keep Jehan away from bug fixing. And that is the third important topic here.
Bug fixing
The situation with bugs in GIMP — and I’m sorry I have no other words for this — is getting out of hand. They recently passed the 4K mark, which is, like, a 30% increase in just about a year. Of those 4K+ bug reports and feature requests a whopping 624 bugs are crashers. And that is just crazy.
One possibility here is to declare amnesty for all bug reports filed against the current stable series and then reopen the ones that will be reproduced by users in the new release. That would be a quite horrible policy of dealing with bug reports. But given the bug reporting dynamics and the availability of developers, I just don’t see any other way to handle this. It’s that or never getting to actually do the release.
There are many more things I’m still concerned about. The incorrect scale at which the canvas is rendered on HiDPI displays, the insane controls in tool settings, and other things.
Look, I’m just being realistic here. Completing this release is going to take a huge toll on the team. If you are in a position to help them with stabilizing the program, please consider doing so.
Once 3.0 is released, we can have a long conversation about the way the team plans their work, which is not great, and the way they finance it, which is even worse. But right now the community needs to finish off this SOB of a release.
Patreon subscribers get early access to my posts. If you are feeling generous, you can also make a one-time donation on BuyMeACoffee.
