2.10, was: wxWebkit

[Stefan Csomor]

Robin Dunn wrote:
> Vadim Zeitlin wrote:
>
>> KO> What I don't understand is how we're supposed to "overcome" 
>> these  KO> issues from our end, except perhaps by forcing wxWebKit to 
>> be  KO> dependent on the wx release cycle and taking whatever delays 
>> that  KO> implies.
>>
>>  If the main issue is the absence of 2.9 releases, then we can make 
>> 2.9.0
>> relatively soon.
>
> It might be good to interject here an idea that I discussed with 
> Stefan last week.  The idea is that it may still be quite a while 
> before we're ready to have a 3.0 release, but in the meantime it would 
> be good to have another stable series where we can get some new 
> features added that can't be put in 2.8 because of ABI issues.
>
> So to do this we could change the version number of the trunk to be 
> 2.99 to make it clear that it is going to be 3.0 when it stabilizes.  
> Then we can make a new branch from the 2.8 tree that will become 
> 2.9/2.10.  I expect that this 2.9 would have a relatively short life 
> before 2.10 is branched because it won't be a target for the really 
> big changes and enhancements like 2.99 is, and it is mainly intended 
> for things that we wish we could put in 2.8 but can't.  Stefan has 
> some changes and additions that would fit in this category, and it 
> sounds like some of the wxWebKit code would fit here too.  When that 
> (hopefully) short burst of activity is done we can declare it done and 
> make the 2.10 branch and release.  I don't think that it would 
> significantly increase work-load because since it is intended to be a 
> short time before 2.10 is available we will be able to phase 2.8 out 
> sooner than we would have otherwise and so work on that branch can 
> taper off sooner.
As Robin already mentioned, this seems - given my and other people time 
constraints and our binary compat police - a good step

+1

Thanks,

Stefan