Movingranges branch

[Andreas Pakulat]

On 07.08.10 11:34:37, David Nolden wrote:
> 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).

Well, its not like much (if anything) happened wrt. language support in
master anyway. Mostly other things are being worked on there (or in
other feature branches).

> > 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.

Strange that everybody (well at least 2 people) instantly jump to the
conclusion that this is going to happen anytime soon. FWIW I don't see
this happening in the next 2 years to come (unless we gain a lot more
developers interested in working on a good/stable API). That doesn't
change the fact that we should try to work towards an API that doesn't
change with each release.

> We've seen in kate the pains that it causes. All kdevplatform-based
> software I've heard of is open-source,

Wether its OSS or non-OSS doesn't matter, what matters is that if you
break the API with each release you're causing pains for those people
who do use it. They have to adapt to the changed API, they eventually
have to maintain multiple branches or they'd throw off their users by
requiring a new kdevplatform version with each new release.

> and it's no problem at all for distros to rebuild all
> kdevplatform-based apps with each update.

Don't let the packagers hear that attitude. Even if its just 3 apps that
need rebuilding on each minor release that is a problem for them. It
means rebuilding 4 source packages on n architectures and having to
maintain nx4x2 binary packages (at least) (wrt. bugreports etc.). Don't
underestimate the effort needed to package software.

Andreas

-- 
A visit to a fresh place will bring strange work.