On Mon, Mar 23, 2009 at 8: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. > then stick a _ in there and add a __all__ and they are not "public" anymore, you can't seriously think they are "public" api in python there is no such thing about that. And those functions are never called from the outside unless you are doing something special (like pages, which is a prototype of a tg2.1 app)
> 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. > I have never seen adding a method as a bad API change, if you use it it's because you need it if you don't use it then what's the big deal? > 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. > how? did you quoted the whole file in the article? that's the only way I can see that your "text is outdated" if you simply said "now add to your websetup at the end of it the following code" they should be no outdated article. > >> 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! > YES, which I propose a way to fix that and you totally ignored it on your response. > For your information, those three items were taken as *blocker* *issues* and I > had *explicit* *permission* to implement them right away. > The above *also* had *explicit* permission, just look at the top of this thread. that's everyone saying +1 > >> 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"? > yes you will lose it for 2.0. > >> (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. > not if you are careful a ton of projects are very trunk stable and I believe TG is one of those. > 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. > I think not, as your last response was a full "complain" of everything I got "wrong" and yet it seems you skip the sole paragraph where I proposed a solution that will get everyone happy. > 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 -~----------~----~----~----~------~----~------~--~---
