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 -~----------~----~----~----~------~----~------~--~---
