Krita 1.6

[Bart Coppens]

On Sunday 05 February 2006 21:58, Boudewijn Rempt wrote:
> Then there's the consideration what wainting to release until we can
> release with KDE4 will do. Realistically, for KDE4 we're looking at mid
> 2007, which is a Bad Thing, and one that I've gotten really angry about.
Yes, that is the big problem; both for users and (aspiring) developers. We can 
complain all we want, but if there's no kde4libs to release against, there is 
no new KOffice possible either. So a split in the near future is bad for:

* users, who want to have access to the (over)hyped (new) features of both 
KDE4 and KOffice 2. Also, having a release an indefinite amount bigger than 1 
year from now gives us a disadvantage over gnome/gimp, who have their 
releases every 6 months/whenever they like. In that time, they will seem to 
making much progress, while we sit at the sidelines, porting and waiting on 
KDE4.

* developers, since the longer we need to have a split kde3/kde4 build system, 
the more we need to recompile part of it, which is boring and sucks. Also 
with a kde4 in full development, their will be regular (2-weekly I think?) 
mergings of the current unstable libs copy with the stable one, probably 
breaking half the stuff. This then in turn keeps us from adding cool plugins 
since we have less time to test them (that applies more to Krita than the 
rest of KOffice btw, since Krita is more feature-plugin based than, say, 
KWord, that would probably have more benefits from larger redesigns).

* aspiring developers, because telling interested people that they can choose 
between
a) Making a Krita 1.5 plugin in playground, which will never be released 
officially together with Krita but must be refactored anyway. With the big 
possibility of it falling into oblivion because in the meantime Krita 2.0 
changed API and nobody cares about the plugins in playground until it's too 
late.
b) Let the developer use the funnily unstable KDE4 and KOffice.
Both choices don't seem to be really appealing to new developers...

> Give me a stable libs in March, and we can release our next version, with
> Qt4 goodness in October. But we're apparently not going to get that. And
> while we have a technology lead now in the free X11 software world, it's
> not solid, so we cannot afford pulling a gimp and telling people they'll
> have to wait a couple of years for the next version.
Exactly. May I also remind people that the idea I have seen, that of releasing 
a prerelease or beta of kde4libs together with koffice2 so that we can 
release sooner is a _BAD_ idea.

> And then again, there are some things to avoid: if we do a 1.6 based on
> KOffice 1.5, and at the same time a port to 2.0, I am very, very sure that
> both Krita's will wildly diverge as to their core api's, which may even
> mean creating a nearly-perpetual fork, a kind of gimp-gegl situation, where
> the cool technology is Qt4/KDE4 based, but the functionality Qt3/KOffice
> 1.5 based, and too much to port, ever.
Indeed.

> One possible solution is a 1.6 release with small core updates (but not
> changes in, e.g. the colorspace api, just adding stuff, not changing
> existing things) and lots of new filters, plugins and other fun stuff.
Yes, this is what Cyrille and I suggested on IRC last night. Some smallish 
core changes, some i18n or UI changes and lots of plugins (but we say that 
every time ;)).

> After all, there are people who like doing core stuff (me, Casper, Bart,
> Adrian), and people who prefer adding features (Cyrille, Michael, me again)
> (and tell me if I've got you pigeon-holed wrong). So it would not mean less
> hands to work on the port, and it would mean only marginally less hands
> working on the features for 1.6. In that case, we need to really agree &
> keep our promises on keeping the 1.6 basicaly a 1.5 + features, not more.
Well I'm mostly interested in core stuff, but I like to play with thinking of 
adding new features all the time ;-) But if we'd do a 1.6, doing only small 
changes is a must indeed.

> On the other hand, if kdelibs4 offers us a relatively stable library --
> even if the api is not stable, I'm just talking about being to compile
> against a snapshot and run the app without it crashing because of kdelibs,
> then porting Krita to Qt4 will take less than a month. And then we can
> start hacking features again and having fun with snapshot releases that
> include our copy of kdelibs4.
Snapshot releases with kdelibs4, not bad per se, but such snapshots will be 
quite big (losing our edge over, say, openoffice).

> Finally, I would like to note that, historically, we've never been able to
> do more than one release a year. And that's not laziness: releases cost
> time, freezes take three months, the thinking and mulling about new
> development takes a coupe of months, there are holidays and so on. A 1.6
> release in September would mean a different release dude from me, too :-).
Well that's what I feared as well. There are lots of other people who could do 
it with good guidance, but I guess release guy schedules are much more prone 
to interfering with real life schedules, than the regular 'just get your 
features/fixes in before the freeze' schedule.

> So: options are:
> 1.6, but no core hacking, just fun features and plugins. Release in
> September (which means freeze in July!) 2.0 in parallel.
This is my personal favourite, but the idea of freezing in July might be a bit 
soon after the old release, hmpf. I wonder, though, if with good planning 
(hah!), we couldn't let the features get added later? (Like if we say that we 
mainly will _add_ strings, i18n might start translating them before string 
freeze without much uncertainty as to how much of them will get deleted.) 
Also, because this release probably wouldn't include a new KWord/Karbon/etc. 
release, it would mean less new documentation and strings anyway...

> 2.0, but a quick port followed by a thoughful implementation of new
> features. Freeze in December, release in February, March 2007
In principle I have not much against this, but I fear the practical side of 
this is unfeasible.

> Release of Cyrille's cool plugins pack whenever we hit a milestone there.
> Maybe every two months?
Good idea, but then they'd probably need a release guy since it'd involve 
i18n, documentation, packagers, and so on.

>
> No options should be, for me:
Agreed on all three no-options.

Bart Coppens