On Jan 25, 2007, at 5:39 PM, [EMAIL PROTECTED] wrote:
>
>>> this refactor had already appeared in trunk, and it make adding a
>>> new tool more tangible.
>> +1. But stay on guard to avoid extra coupling with other parts of TG
>> because the ToolBox will likely be refactored out of TG's core (but
>> bundled with TG), try to make this step as easy as possible for the
>> future refactorer.
>>
>
> Yeah, that's the intention for the toolbox refactor appeared in trunk.
>
> Introduce a new feature to public is the quickest way to get response,
> if it is cool, we could took it off to be an extension for future
> version.(as those template extensions)
Yep, that's my point. I wasn't asking for decoupling right now, just
avoid *more* coupling if possible... :)
> Since to ship an extension will cost some extra effort.(especially
> there's none existed reference about standalone toolbox extension).
> BTW, It's the toolbox because it's battery included, right?
Well, extra effort for the packager, not the user... the user has
"easy_install" Keep in mind that separate-packages is just an
organizational convention ("organizational" in the sense we'll have
package owners to bug when we want something ;) which has the side
effect of defining clear interfaces with the rest of the world (this
is good). Batteries included means a "requires" line in setup.py. so
TG can still be batteries included although it's batteries are well
encapsulated batteries.
>
>
>>> So, is it ok for me to branch a project(another code name or 1.1) in
>>> svn to experiment these features?Hmmm, I rather keep this at the
>>> trunk to get the most users and
>> testers. Now that 1.0 is out and the 1.0 branch is the "untouchable"
>> one the trunk is there to break it as much as you like ;)
>>
>
> I understand your consideration, but I hope we could quickly get tg
> 1.1, even 1.2, the 'feature-freeze' statement keeps too long.
>
> "practicality beats purity"
Agree. That's why 1.0 lives in a separate branch where *only*
bugfixes or implementing basic, easy and non-risky missing features
which are just not there but expected, the inclusion of a test.cfg is
a good example (and it fixed some bugs by accident ;), fixing broken
paginate another... Experimentation and new features in trunk is
encouraged, but 1.1 should take extra care to make a migration from
1.0 as painless as possible so thinking of how it will affect
existing code is a must. Every breaking change should be avoided or
provide very good documentation, deprecation warnings, so it's easy
to upgrade. This is why I don't want to include TW in 1.1 as a
default yet, for example.
>
> It's time to do something more aggressive like we did in 0.8->0.9
> (many
> new features were introduced, but not make them separate as extensions
> yet).
Making new, complex feautures as separate extensions does require
some effort but it pays off in the long run. I find contradictory to
introduce new components in TG's core when we're aiming for exactly
the opposite in 2.0. I'm not saying 1.1 should start decoupling now,
just not introduce *more* coupling :). Re-using the TW example: I
could have coded TW inside TG's trunk but decided that if I wanted to
be usable outside TG, rebuilding widgets outside TG sounded like a
better idea. It took some effort but now TW is usable outside TG and
*inside* TG (even in 1.0)
>
> Users could get some new features(enhancements) that won't break any
> 1.0 behavior. People would try the feature and have some words in
> their
> blog, it will attract more people to TurboGears, that's positive.
If the feature is useful but distributed separately they'll use it
anyway, it's just an "easy_install" away... I don't see why bundling
it inside TG will make things better... In fact, If the feature is
useful and is not tied to TG, it'll get even more attention from
people who want it but don't want the whole TG cow.
>
> I don't like mochikit's release way, I'm feel tired to tell people to
> look some useful features in mochikit svn, if it is useful and
> stable,
> why not release a new version?
This much proves my point :) If MochiKit was not included in TG's
core it would be much easier to upgrade it without risking breaking
user's code. If someone doesn't want latest 1.4, they can write
"TGMochiKit < 1.4" in their app's setup.py and use the older release.
>
> Release a new version does matter to the host company and end users.
> Since the host company never deploy the svn version to the user and
> they need sometime to test if the version is stable. The end user
> (who
> don't touch svn) won't feel tg has any enhancements these days and
> quickly turned to other frameworks.
I agree and I hope we'll have a 1.1 ASAP so we can start building on
it. I've stated my plans in a post a couple of hours ago for open
discussion. Other features/projects can be developed in parallel with
the priorities I see now which is to migrate to CP3 and implement
paste.deploy's interfaces. However, new projects should not be
included in the core IMO, new features for existing components: yes
(with care not to obstruct a future refactor). The trunk is open for
any experimentation you wish. That's all. :)
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
-~----------~----~----~----~------~----~------~--~---
