[bt-devel] QtWebKit DOM access

[Gary Holmlund]

Eeli Kaikkonen wrote:
> Martin Gruner wrote:
>
>>> 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.
>>
>> I would like to follow a different path. Subsequent releses which do 
>> not only fix bugs, but also introduce new features, in the 1.7 
>> series. Otherwise we'll fail to achieve the "release early, release 
>> often" principle again.
>> Working in HEAD would require discipline to only make changes which 
>> keep HEAD in a releaseable state (not at every point, but most of the 
>> time). We shouldn't make too "radical" changes - and they are not 
>> needed, as Gary outlined.
>
> I have to admit I don't necessarily understand you completely here. If 
> webkit brings in much work, uncertainty and potential bugs, as it 
> certainly will, we can't release it for a while. And yet after 
> releasing 1.7 we should be able to react immediately if we find a 
> crash or someone can't build the source. Otherwise users/packagers are 
> left with essentially beta quality software. Of course the first 
> release can be 1.7.0 and those bugfix releases can be 1.7.0.1 and so 
> on, and the next feature release can be 1.7.1. But then we should 
> branch 1.7.0 and the HEAD is for 1.7 development. Again, #ifdefs could 
> make branching unnecessary, but who can say that khtml and webkit will 
> be so compatible that it doesn't create problems and extra work? And 
> when the webkit would be working we would have to change and remove 
> big amount of code.
>
> Basically I'm still open to any path, but I would like to hear why 
> exactly you are against branching, if that was your point.
>
> --Eeli Kaikkonen _

I believe that using a branch for a 1.7 release is an independent 
decision from how to deal with the changes for QtWebkit. Even if we had 
a 1.7 branch and new development was happening on the HEAD, I would not 
directly check my changes into the HEAD. I believe the HEAD should be a 
close to stable as possible at all times. Otherwise my work would imped 
other development going onto the HEAD.

So, I would need to do something such as using #if or using a personal 
svn branch or use a private source code control. Using the #if has the 
advantage that others can see the work and comment on it or even 
contribute to it. With the change of the #define anyone could compile 
the QtWebkit version. The #if could stay until new feature is considered 
stable and then old code could be removed.

At my work we have used branches. They do cause some extra work to merge 
the branch and trunk. We would prefer to keep the HEAD stable and make a 
new release from the HEAD. We do use branches, but only to do bug fixing 
of a previous release, not to add new features.

Gary

PS   My work is backed up.