Well, it's in and the docs are updated. Dunno what to say, you mentioned this after I had already implemented.
On Mar 18, 6:17 am, Mark Ramm <[email protected]> wrote: > I after a bit more thinking about this, and after seeing the size of > the change, I think I'm back to thinking this will be a 2.1 feature. > But I know it's nice stuff and nesissary for tgext.pages, but the > component stuff is a 2.1 goal, and we do have a feature freeze going > on, and I need to be more hardcore about enforcing that. > > If we can release 2.0 final, and 2.1 a few weeks later, I'm fine with > that, but I don't want to delay or break 2.0 ;) So, to hopefully make > everybody happy, I say we leave this in trunk and declare trunk the > place for 2.1 work, and I'll create a 2.0 branch right away, based on > the rev before this change for the rc1 release. > > What do you think? > > > > On Wed, Mar 18, 2009 at 7:14 AM, Gustavo Narea <[email protected]> wrote: > > > Hello, > > > If we're supposed to be in a feature-freeze, that's for people to be > > confident > > that from now on things aren't going to change, unless a critical bug has to > > be fixed, so that they can start building software and writing about TG2 > > with > > the guarantee that their product isn't going to expire some days later. > > > I love to see TG2 evolve, but that this has been applied in the > > feature-frozen > > branch I'm using to write a short series of articles using TG2 and that it > > already out dates the first article (which was delivered)... It really > > bothers > > me. > > > If I can't trust that we were serious when we announced that feature freeze, > > then I'll switch over to a truly stable framework for my next article. > > > On the other hand, independent of the article I wrote, I think we must > > comply > > with the feature freeze strictly, specially in non-trivial changes like this > > (splitting a function into three ones, defined in newly-created modules > > each). > > > The more complex a change is, the more chances to introduce a bug. And at > > this > > point we shouldn't take the risk of introducing bugs, but just fix the > > remaining ones. > > > Finally, I think this change has to be moved to the upcoming 2.1 branch > > (trunk, when there's a 2.0 branch). I love the idea, I think think it's > > reasonable, but I think it's too late to go in v2.0. Otherwise, this will be > > bad for PRs. > > > Cheers, > > > =Gustavo > > > On Tuesday March 17, 2009 19:05:50 Mark Ramm wrote: > >> Works for me. We can try to shoehorn this into rc1 if we can get it > >> done in the next day or so -- otherwise it'll be a 2.1 feature. > > >> I want it done now, but making that happen will require updating > >> several docs :/ So, I'm a bit hesitant to about just going for it > >> directly. > > >> --Mark Ramm > > >> On Tue, Mar 17, 2009 at 1:53 PM, Florent Aide <[email protected]> > > wrote: > >> > On Tue, Mar 17, 2009 at 4:56 PM, percious <[email protected]> wrote: > >> >> I have begun work on our new extensions methodology. (Some call this > >> >> component architecture). I am working with Jorge and Jon to try and > > >> > [...] > > >> >> websetup/ > >> >> __init__.py : contains setup_app which will be a combination of > >> >> bootstrap and schema setup > > >> > nice this will definitely make things easier. > > >> > Florent. > > > -- > > Gustavo Narea <xri://=Gustavo>. > > | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | > > -- > Mark Ramm-Christensen > email: mark at compoundthinking dot com > blog:www.compoundthinking.com/blog --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
