On Jan 27, 2007, at 4:32 AM, Jorge Vargas wrote:
>
> On 1/26/07, Alberto Valverde <[EMAIL PROTECTED]> wrote:
>> Ok, but make sure that "1.1-toolbox-exp" branches 1.1, which is going
>> to be derived from *trunk*. This means that a "1.1-foo-exp" should
>> branch from trunk due to the transitive property of the previous
>> statement.
>>
> no please don't do that all those branches will just mean patches will
> be more difficult to create/apply, think of bug fixes.

This is the main reason I'd prefer to have less branches, specially  
if there is no significant difference regarding API's and internal  
organization. Trunk is very similar to 1.0 except in the widgets  
(which I'm going to restore in trunk from 1.0) and some enhancements  
to the toolbox

>> If it branches 1.0, then it shall be called "1.0-toolbox-exp" in
>> order to keep naming conventions sane. However, 1.0 is in feature
>> freeze so I don't see any point in experimenting new features with
>> the 1.0 branch...
>>
> I have no idea what you guys did, first there was a 1.1 branch which
> was deleted now there is a 1.1_package_sep_exp?
>
> why not just branch 1.1 of 1.0 and backport stuff from trunk?

Trunk is 1.1. We've been forward merging changes to 1.0 into trunk  
for months.

> what I don't want right now is what happen with 0.9 and trunk that
> each and every commit had to be done to both because the branch was
> there for way too long. if 1.1 is going to have this much features
> (sa,genshi,tw,refactoring,etc) then just release 1.1 out of the trunk.
> and then build 2.0.

Plans for 1.1 are in the "TG 2.0 update" thread. The subject is  
rather misleading because I'm touching 1.1 issues most of the time.  
What I tried to get through is that:

* CP3 and paste.deploy are targeted for 1.1
* 1.1 development can start now
* 1.1 will come out of the trunk
* 1.1 should be be 95% compatible with 1.0 and that 5% should be very  
well documented :)

2.0 involves a more serious shakeup of TG's foundations in order to  
reduce the core by moving TG's services into separate projects. 1.1  
will enable this because 1.1 apps will  be abe to integrate WSGI  
components more easiliy and be used as WSGI components of a larger  
site (thanks to CP3 and paste.deploy)

I'll try to be more explicit now in order to avoid confusion. The  
three points I'd like to stress out are:

* The trunk is 1.1 and 1.1 is the trunk
* 1.0 is featured-freezed and should only incorporate bugfixes
* Experiments with 2.0 can start in a separate branch, however, I  
think 1.1 must get some shape before this can happen... at least 1.1  
must be ported to use CP3

> is there anything left on trunk that doesn't belongs to 1.1? are those
> feature worth the wasted time doing two commits?

The only thing in trunk that doesn't belong in 1.1 are the widgets,  
which should be copied from 1.0 (*not* TW, TW is for 2.0) because the  
widgets in the trunk are broken (I know... I broke them ;).

>> I'd also advise to take the time to keep a 1.1 branch in sync with
>> 1.1 (trunk)
> huh? you mean 2.0 trunk? or you mean branch 1.1 of trunk and not 1.0

Exactlly, I mean "branch 1.1 from trunk" when we decide to start  
stabilizing it for a release (like we did with 1.0). I wouldn't do  
this now because there's work pending for the 1.1 milestone and  
making a branch now will force us to keep trunk and 1.1 in sync *and*  
merge bugfixes from 1.0 into both (phew, I'd have to write yet  
another script to do this, 3 separate workingenvs and 3 times the  
trouble....) I'd prefer to branch 1.1 for stabilization once we've  
moved to CP3 and we implement paste.deploy's interface to build WSGI  
apps.

Alberto

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to