Movingranges branch

[David Nolden]

2010/8/7 Niko Sams <niko.sams at gmail.com>:
> Keep in mind that more (active) branches mean more work. Especially if it's not
> that easy to merge between them.
> So I vote for creating a 4.1 branch, discontinuing 4.0 branch and
> merging movingrange
> into master. That way we have the same number of branches, do the same
> merges and
> still have a new release.
>
> But where merge Milian's multiplelanguages branch? Maybe 4.1 so we can
> have a first
> Quanta release that depends on KDE 4.4.

If multilang would go into the branch, it would mean that we would
split up the whole development across 2 different branches, which
would really suck, as it would reduce the tiny amount of testing we
can do even more, and overall it's wasted time. I think the
development of the non-movinranges branch should be stopped as soon as
possible (especially regarding language-supports), because you might
end up doing a lot of fixing and polishing of code that will be thrown
away/removed in the next release anyway (language-supports are less
complicated in the movingranges branch).

> Oh, is there planned to keep an stable API/ABI for kdevplatform at
> some point? The decision
> for a 4.2 should not influence that...

I'm against this in close future. We've seen in kate the pains that it
causes. All kdevplatform-based software I've heard of is open-source,
and it's no problem at all for distros to rebuild all
kdevplatform-based apps with each update. I don't want to see
ISessionControllerV2 interfaces etc. in kdevplatform. Even the
binary-compatible split between ktexteditor and kdevelop is a pain
already.

Greetings, David