BIC monday! (was Re: BIC monday?)

[Stephan Kulow]

Am Monday 24 February 2003 17:02 schrieb George Staikos:
> On Monday 24 February 2003 09:32, Benjamin Meyer wrote:
> > On Monday 24 February 2003 1:50 am, George Staikos wrote:
> > > On Sunday 23 February 2003 15:51, Volker Augustin wrote:
> > > > Hello,
> > > >
> > > > what was the final outcome of the "BIC monday / friday" discussion?
> > > > E.g. today the KAutoConfig classes where changed. And as kaudiocreator
> > > > now uses the new API it cannot be compiled against a 2-day-old kdelibs.
> > >
> > >   That has nothing to do with BIC.  It has to do with new code being
> > > added. New code will be added to kdelibs on a regular basis, and code
> > > outside kdelibs will use it.
> >
> > Well it was about the same sense I added the new code to kdelibs and
> > commited the usage code at the same time to kdegames and kdemultimedia.  It
> > has the same effect on developers as BIC.  I should have waited and
> > commited it on Friday.  (Is it Friday?)
> 
>   If we have to wait for doing that, nothing will get done.  For instance, I 
> added a few new methods to kglobalsettings and then proceeded to edit > 100 
> files in all the modules in CVS (I don't know how many were changed in the 
> end).  I didn't receive a complaint of similar nature to this.  The real 
> problem occurs when you actually break BC, and so everything has to be 
> rebuilt or it dumps core.
> 
Right. New code has to be tested and new code in kdelibs means perhaps changed
interfaces and new usages in kde*. But if you break BC, then only commit on monday,
otherwise you _have_ to recompile everything. If it's just about the new xinerama, you
can compile application per application as you like to have it. But if a new kdelibs means
binary incompatible interface, then you can't use your week old KDE with it and it hinders
you work. 

So if someone has a compilation problem, he should update kdelibs. And if the day is
!= monday, he can be sure he only has to update kdelibs to get it working again. I hope,
that's a good enough compromise. Of course larger changes should be thought out well
enough, so they don't require yet another change the next day - but shit happens.

Greetings, Stephan