policy change related to kdelibs snapshots

[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 
wouldn't need the kdelibs snapshot anymore, but use trunk for it. We could 
impose the policy we used in the past, that binary incompatible changes only 
can be made at a certain interval, e.g. every second Monday. This would then 
be the date where the bleeding edge branch is merged to all modules. So 
application developers could use kdelibs trunk without the need to recompile 
every day together with trunk of their module and they could also help with 
fixing bugs in kdelibs more easy, because they could work on the version they 
have checked out without needing to backport patches.

-- 
Cornelius Schumacher <schumacher at kde.org>