policy change related to kdelibs snapshots

[Benjamin Reed]

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

> I doubt that the Benjamins (both of you) are developing applications - right?
> It's the application developers that need a stable libs to work with, and
> that's what kdelibs4 snapshot offers. The only problem was that this made
> kdelibs developers make unrealistic changes, and that's what "more use of
> bleeding edge" (by kdelibs developers, anyone else doesn't need to care)
> solves.

Yes, we (the company I work for) develops applications *and*
frameworks that those applications use, and the way it works here is:

* trunk is always compilable and ready to send to QA
* work on sweeping changes always happens in a "feature branch"
* when the feature is done, and stabilized, you merge latest trunk to
the feature branch, fix compilation issues and integrate API changes
that other people have merged to trunk since you branched, and then
merge that finished, integrated feature branch into head

The way we work, your sweeping changes always happen in discrete
chunks (refactoring done, merged to trunk), rather than
helter-skelter.  Right now in KDE, you have the choice of snapshot
(out-of-date and possibly incomplete or unfinished, but at least
compilable, refactorings) or bleeding (definitely in the middle of
refactorings).  That choice is between "it'll compile but I'll have to
change my code again as they figure out how this refactoring *really*
will look in the end" or "it may or may not compile, and things are
constantly changing out from under me."

Just my $0.02 -- right now it seems like we have the worst of both
worlds.  Bleeding edge, where almost-always-broken-code lives, or
snapshot, where it's not only out-of-date, but has
unfinished-but-compilable code in it that will likely change again.