forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: svn commit: r367799 - /forrest/branches/dispatcher/
Date Fri, 13 Jan 2006 09:46:18 GMT
David Crossley wrote:
> David Crossley wrote:
>>Thorsten Scherler wrote:
>>>Ross Gardler escribi??:
>>>>Thorsten Scherler wrote:
>>>>>Ross Gardler escribi??:
>>>>>Thorsten Scherler wrote:
>>>>>>>yeah agree, so what do you suggest? Like said I do not see the
point in
>>>>>>>a 100% copy if I change <5%.
>>>>>>That is not how branching works. When you create a branch it only

>>>>>>creates copies of the parts that are changed. Therefore, doing an
>>>>>>switch" is really quick and easy.
>>>>>>Since you have found your requred changes will affect trunk, I'd suggest

>>>>>>using a proper branch.
>>>>>What speaks against "just create the final dispatcher
>>>>>plugins (like I did in the branch) in the trunk and leave v1 and v2 in
>>>>>our trunk till we have pelt contracts working with the dispatcher"?
>>>>I may have misunderstood, but I thought you said that your changes would 
>>>>couse problems in trunk and that is why you finally decided to use a 
>>>Yes and no. Yes if I use the v2 plugins directly, no if I start new
>>I too was confused about the previous statement that
>>the next phase of Dispatcher work would break trunk.
>>I presumed that that meant the current skins, hence
>>the need to branch. I also wondered if it meant that
>>the work was happening in the existing structurer and
>>themer plugins, hence the need to branch.
>>>>The only other thing that worries me is that there are already two 
>>>>different versions of views in whiteboard, you are now working on a 
>>>>thir. It is getting very confusing (your title is well deserved ;-).
>>>jeje ;-)
>>I too find the technique of copies of plugins confusing
>>and hard to manage and hard to keep documentation
>>>I totally understand you and we need to clear out the confusion. Still I
>>>think creating 2 new plugins would be quickest and easiest way. I will
>>>start clearing the v1 plugins then we have the same number of
>>>plugins ;-)
>>That is still too many.
>>We should bear in mind that we have emphasised that
>>the Dispatcher work should not be relied upon. So we
>>are safe to make radical changes. We can assume that
>>whoever is using it, is also reading the dev list
>>with glee. They probably have a copy of a working svn
>>to manage their current website and local development,
>>and they have a local version of the matching docs.
>>Other brave souls are at the head of trunk, so no need
>>to worry about them.
>>So i reckon that we do not need to support versions
>>of rapid development work.
>>When the next minor hurdle of Dispatcher development
>>is ready in a branch, then we announce it on the
>>dev list and then just do it. Everyone then can decide
>>for themself whether to 'svn up' or not.
>>Our main Changes for 0.8-dev should state the major
>>changes (and perhaps the svn revision number) and
>>then the rest of the detailed changes are in the
>>plugin's status.xml file.
> What do people think? Is that the way that we should
> handle situations like this?

I agree, it does seem cleaner.

In fact, I was thinking of going a step further in the branch. At some 
point we need to move dispatcher into core and move the skins into 
plugins. Why not do that in the Branch. Thorsten seems pretty sure this 
next version is going to be "the one".

I for one would start using that branch for my own development work.

I would see this branch as being work towards a 0.9 release.



View raw message