policy change related to kdelibs snapshots

[David Faure]

On Monday 10 July 2006 16:54, Benjamin Reed wrote:
> 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

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

> * trunk is always compilable and ready to send to QA
> * work on sweeping changes always happens in a "feature branch"
In a way, kdelibstrunk+bleedingedge is exactly that branch, given the amount of 
sweeping changes happening lately.

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

> or "it may or may not compile, and things are 
> constantly changing out from under me."
bleedingedge is for porting to kdelibs trunk and nothing else.

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

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 :)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).