policy change related to kdelibs snapshots

[David Faure]

On Monday 10 July 2006 18:10, Stephan Kulow wrote:
> Am Montag, 10. Juli 2006 17:12 schrieb Cornelius Schumacher:
> > On Sunday 09 July 2006 21:50, Stephan Kulow wrote:
> > > So I would like to propose that we use bleedingedge for all modules
> > > currently in KDE/ and changes to trunk/kdelibs/ should always come with a
> > > porting of bleedingedge to it. Otherwise kdelibs development will
> > > continue stay out of touch with applications. I kind of doubt the
> > > ksystray change would have happened the way it did if a closer look was
> > > taken on how the applications are using it.
> >
> > I'm not sure, if you meant it this way, but I think it would be good to
> > have bleedingedge for all modules including kdelibs. This way new features
> > and API changes can be developed without affecting application developers
> > who prefer to work on a stable version of kdelibs.
> >
> > If kdelibs would have a bleedingedge branch, it could also mean that we
> All that changes between my proposal and what you said is the name of the 
> branch. But it's fine with me and as it makes sense I guess we should go for 
> that :)

There's just one downside to Cornelius's proposal: we lose the granularity of svn logs then, in the kdelibs-trunk history.
All changes get merged every 2 weeks, in one go.
I don't think we really want to replay all commits one by one :)

So it seems to me that coolo's proposal, although a bit more complicated to grasp
at first (kdelibs_trunk+bleedingedge || kdelibs_snapshot+trunk) is the one that leads to the best
subversion history.

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