policy change related to kdelibs snapshots

[Benjamin Reed]

On 7/10/06, David Faure <faure at kde.org> wrote:

> I meant kde apps in kde subversion, but ok :)

Right, I was trying to show how our methodology would work in the
context of kde development...

> Well, the whole idea of snapshot is to avoid intermediate changes, as they
> would happen if tracking trunk all the time. More than once we changed our
> mind -before- updating snapshot, and this didn't affect the apps *because*
> snapshot exists. Not all changes can be done in a work branch, when they
> affects a few apps with many dependencies.

My impression is that it didn't really end up working that way very
much.  Perhaps I'm mistaken.

I think ultimately, the problem is coming from the "kdelibs-only"
approach.  The apps reallypretty much need to be branched along with
libs if API changes are happening, it's really the only way to make
sure things stay in step.

Putting everything in bleeding should in theory solve that issue, but
it still seems like we're kind of ending up with 2 bleedingedge's, one
more stable than the other, rather than unstable + something app
developers can really use.  Granted, the dbus move was a special case,
it was ripping out something that nearly every KDE app ended up using
in one way or another.  No getting around it, things have to be broken
for a while in that case.

> 2 weeks isn't so out-of-dates, and there's no branch that can give you
> kde-4.0-final api at this point :)

:)

There's no 4.0 final API, but it sure seems like 2 weeks is pretty
out-of-date at the current rate of development...  <grin>