Honestly guys, if you want a bug for this change I can produce one in about 30 seconds.
$ paster quickstart tgtest $ cd tgtest $ paster setup-app development.ini <change model> $ pastser setup-app development.ini <error ensues> My change fixes this bug and is a minor refactor. This is the biggest reason I re-wrote that code, and if you want me to post a bug on it I will. And I agree with Jorge, it's not an api change due to the fact that the same external imports are functional. API = application programming interface, ~ not ~ application programming internals. cheers. -chris On Mar 23, 6:02 am, Gustavo Narea <[email protected]> wrote: > On Monday March 23, 2009 07:29:54 Jorge Vargas wrote: > > > Please explain me why this is API change? > > <snip> > > please tell me how the calling code changes from A to B ? It doesn't! > > so please do not say that is an api change, it isn't. > > I repeat: If you add two public modules and two public functions, then you're > changing the API. I'd say it's pretty obvious. > > You seem to believe that API change == backwards-incompatible change, and > you'd be wrong. You can make backwards compatible changes in the API -- for > example, the one we're talking about. > > Nobody but you is talking about backwards incompatibility. Of course that > function can be called as usual, it's backwards compatible! So what? Who's > said it's backwards incompatible? Nobody. > > My point is that it's an API change and that always outdates text written > relying on the part of the API that changed. Period. I didn't say that > function has to be called differently since that change. > > > The only think that could be affected by that change is that if you > > told someone to edit websetup.py instead of websetup. > > Why? Because it's an API change! > > > > > So why not look for a mid ground instead of killing the feature? make > > it back into a single websetup.py and let it be split into 2 functions > > all in the same file, everyone is happy, then make it a module for 2.1 > > > It seems to me everyone saw a bunch of files be moved in > >http://trac.turbogears.org/changeset/6513and didn't realize how > > trivial is that. > > > Now lets see the feature freeze was supposed to be feb-28 (from ML > > archives) yet if you look at > >http://trac.turbogears.org/log/projects/tg.devtools/trunk/devtools/te... > >s, we'll have to remove > > > - the move of the ModelTest class (which I didn't because we where in > > api freeze) > > - all the new model tests > > - all the new auth tests > > For your information, those three items were taken as *blocker* *issues* and I > had *explicit* *permission* to implement them right away. > > > so what's it going to be are we willing to "lose" all the last changes > > Will you continue referring to moving that enhancement to 2.1 as a "lost" or > "discard"? > > > (and confuse everyone running trunk) > > Confuse everybody running trunk? Here and in every single project it's more > than explicit that if you use the mainline development, you'd be doing it at > your own risk. > > So that's not a reason to be taken into account. > > > or we are going to look for a solution? > > I think that's what we're doing. > > Cheers. > -- > Gustavo Narea <xri://=Gustavo>. > | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
