[bt-devel] QtWebKit DOM access

[Eeli Kaikkonen]

Martin Gruner wrote:

> 
> I'd prefer Gary's suggestion. Branching creates the risk of loosing changes and requires significant effort to keep things in sync.
> 
> With (a limited number of) #ifdefs we can stay in head, and whenever the new code is good enough we will switch, removing the old one.
> 
> Using a subclass instead of some #ifdefs is possible, you two can decide which is better. We should not use branching though.
> 

I'm not a version control system expert so I can't defend branching. But 
with logical thinking I come to conclusion that if someone has a private 
branch home it has almost the same problems. Gary should update his 
private codebase with all public updates so that he can merge back 
easily. (I highly recommend git with git-svn for that. I use it with 
several private branches which I keep in sync with the SVN HEAD and from 
which I commit to the SVN HEAD.)

"Requires significant effort to keep things in sync" - this would not be 
a great problem with a distributed vcs, they are created for easy 
branching/merging and easy changing of patchsets etc. But I don't see 
why this would be a great problem even with SVN. If the 1.7 branch would 
get only small/important bugfixes + bookself manager fixes keeping it in 
sync shouldn't be hard. We could put all KDE->Qt changes to the webkit 
based HEAD only.

I see also another reason for 1.7 branch: if we release 1.7 in HEAD and 
then change the code radically it will take much time before we can 
release a new stable version. There will surely be bugs in 1.7 which 
need immediate fixing (crashes and build problems) because we don't have 
enough testers now. Those fixes would be easy to put into 1.7 branch and 
then release 1.7.1 etc. if needed.

--Eeli Kaikkonen