I actually prefer the "when it's done" model rather than the "train leaving the station" model, for software like this. I feel it better allows for broad-scope changes, which may touch large swaths of a codebase, to more fully gel/mature before being released. For something that I might only update once every few years anyway (ie: not very security-critical), it seems worthwhile to reduce the overhead of release process/logistics for the developers, letting them spend that time on features/fixes instead.
Or maybe there was another model you were suggesting? What do you find non-sane about the current one?
They basically stopped doing the previously-usual updates for a 7 years to focus on porting to GTK+ 3; GIMP was very tied to GTK+ 2. There were a bunch of much-anticipated features (esp. non-destructive editing) that were finished but couldn't be released because it was half-way through the big GTK transition.
Hopefully the now-impending port to GTK 4 will be a lot smoother and won't be such a disruption to their ability to ship the features they've been working on.
If those fixes take years to get released, that's not really a good thing. One year with bug fixes is typically okay unless you're dealing with hardware.
From the release notes: "we also intend for minor releases to be much more frequent. Rather than having another 6+ years development schedule for GIMP 3.2, we plan to release it within a year of 3.0".
interroboink|11 months ago
Or maybe there was another model you were suggesting? What do you find non-sane about the current one?
LukeShu|11 months ago
Hopefully the now-impending port to GTK 4 will be a lot smoother and won't be such a disruption to their ability to ship the features they've been working on.
bb88|11 months ago
yiyus|11 months ago