On Thu, Jan 12, 2006 at 04:48:21PM +0100, Valentino Volonghi wrote: > Where something is located doesn't matter that much. It's still code that has
Where something is located doesn't matter, but having to checkout 10 different things when a single checkout command would make it the same way, seems quite unnecessary to me. If we were talking about huge repositories, then saving network bandwidth and disk space could make sense, but for small things that totally depends on nevow, the annoyance is more than the benefit. > I wouldn't walk this path at all. We are providing backwards compatibility for > nevow versions that are long gone and we will provide it even when moving to > web2. But notice that nevow is quite a bit different than python in many ways. Yes, and I can report that I had zero breakages in my code so far. But moving away from formless isn't going to be trivial and infact I'm deferring it as long as I can, because I don't want to risk forms to suddently change API after I ported to it. The later I move into forms, the less risk of wasting time ;) > But still even bigger projects break backwards compatibility (Zope, Python > itself, Cherrypy between version 2 and 2.1, Ruby on Rails itself) when needed. Even the kernel does. But here I'm seeing quite a few projects being advertized and after one year going in "obsolete" mode and being replaced right away with something else written from scratch. Atop is one example. It's not all necessairly bad, but especially after seeing atop, I wouldn't even dream to touch axiom for example. I've to thank you a lot for suggesting me to use postgresql as backend, that was a good and correct choice for my web apps. > To be honest I don't care that much. I do as much as I can to help people and > to develop Nevow with the time I have available. If people is so stupid to > leave a project because it is evolving to help developing with it then fine, I > don't care at all. I was especially talking about breaking stuff without a good reason for it. I trust you for the direction of the project, my message is more a "think twice before breaking stuff", than "never break anything". I perfectly know sometime something has to be broken sometime. But I wanted to make my point that porting from formless isn't trivial and that obsoleting formless may hurt some users currently depending on it. > As I said we will have backwards compatibility code. Worrying about something > that is not even started seems a bit out of place. I have applications that > run on Nevow too and I won't be happy to fix them all indeed. I'm not worried, I'm sending my opinion before it starts exactly to perhaps influence future decision. I wouldn't like a project that never evolves because it's forced to remain backwards compatible, but at the same time when major apis are obsoleted and replaced right away, something smells like not enough attention is being paid. One perfect example of this, is how can I be getting a formless deprecation warnings if formless is obsolete? Who had this idea of changing formless with yet another API? formless currently asks me to add some bind method and to stop using the interfaces. So now we've _two_ formless APIs, and both of them going obsolete soon. I'm certainly not porting my code to the new-formless-already-obsolete API when I know I will have to switch to forms in a year or so. And furthermore I'm not even switching to forms until I'm forced to, to reduce the probability of forms breakages. So I think I'm right asking to be more careful, because this new bind method formless API is the proof some effort is being wasted. _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
