Forwarding headers for ThreadWeaver

[Kevin Ottens]

On Thursday 02 January 2014 17:14:36 David Faure wrote:
> On Thursday 02 January 2014 16:26:33 Mirko Boehm wrote:
> > Hi,
> > 
> > On 02 Jan 2014, at 15:37 , David Faure <faure at kde.org> wrote:
> > > On Thursday 02 January 2014 15:29:13 Mirko Boehm wrote:
> > >>> The official way used by all other modules would be
> > >>> threadweaver/job.h (lowercase real header) and
> > >>> ThreadWeaver/Job (forwarding header)
> > >> 
> > >> Ok.
> > > 
> > > Is this a green light for us to convert all of threadweaver (and its
> > > users) to this scheme? (or do you plan to do so?)
> > 
> > Actually, I *know* I have unpushed changes at home where I started with
> > the
> > class renaming. These will very likely clash with header file renamings.
> > So
> > I can take care of that on Saturday. If I need help, I will holler on IRC.
> 
> OK.
> 
> > Please wait, for the same reason as above. If you want to, we can set a
> > time for Saturday and meet, and get everything ready. Sorry for being a
> > pain here :-)
> 
> I'll be online Saturday 10h-12h and probably 17h-20h.
> 
> > What you could do is change the occasions you find that use the Weaver/
> > subdirectory to use the official include directory. Then removing the
> > subdirectories should not affect anybody outside of the ThreadWeaver
> > source.
> 
> OK, pushed in
> http://commits.kde.org/threadweaver/f64082bc9a0ae3de47b47edcf95298e424326b5c
> to at least make it the same everywhere .
> 
> > >>> I want to release TP1 asap (i.e. once all forwarding headers are
> > >>> installed), but SIC changes can still be done afterwards.
> > >> 
> > >> Threadweaver cannot be released before the class name changes are done,
> > >> because those will be source incompatible. I get back tomorrow night,
> > >> and
> > >> will finish it on Saturday. After that, all other changes are
> > >> incremental
> > >> and BC, so the release would get unblocked. Sorry for that.
> > > 
> > > As I said, TP1 does NOT include a SC promise, it's ok to make SC changes
> > > afterwards.
> > 
> > The class name changes will be source *in*compatible.
> 
> Oops I meant "it's ok to make SIC changes afterwards".
> But OK, while that's true for all other frameworks, if we maintain the idea
> of karchive and threadweaver being "final" then it doesn't apply to
> threadweaver.

They don't need to be final. SIC in them post-TP1 is fine to me.

Really this statement keeps creeping up I don't really know how we went from 
me saying "we'll make a TP1 around december containing at least karchive and 
threadweaver" to everyone saying "we'll make a TP1 around december containing 
the final 5.0 versions of karchive and threadweaver". :-)

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140102/089a76b4/attachment.sig>