Yea Massimo, thats the point, I don't know if there are really big issues and it seems actually there aren't. It's almost a mind question to you and big developers, is there any big issue to consider non backward? It seems is not by your comments, :-D
El 06/08/2009 7:05, mdipierro escribió: > To my knowledge there is no issue cannot be solved in a backward > compatible way. > > Most of the issues that Armin raised about web2py have to do with its > internal design decisions. These are not bugs to be fixed. These are > distinctive features of web2py that were thought through before being > developed and I see no reason to change. Every design decision has > pros and cons. > > Some of the issues like the "open file issue" do not constitute a bug > (we have no knowledge of any problem with it) nevertheless this has > been addressed in trunk already. > > The issues with "request.now" is non-existent. request.now is just a > variable that contains the localtime when a request arrives. It is a > variable that you can use in your programs. It is true that by the > time a request arrives until a request a request ends time passes by, > by there is no race condition. We simply provide a variable to the > users to know for sure when the request arrived, the current time is > in datetime.now(). > > The issue with now vs utfnow, althought I dismissed because it would > break backward compatibility, I should have been more extensive. The > OS timestamps files using the local time, not utc time. The average > developer prefers using localtime vs utc time. If you store things in > database and you have multiple servers over multiple timezones than > you want to use timestamp records using utc time instead of local > time. Except in this last case localtime is to be preferred and that > is why we store in a variable. If you need utf time that is also > available via the datetime module. > > I am not sure there is any open issue here. Which issue in your > opinion would need a backward incompatible change? Not that this is > going to happen. > > Massimo > > On Aug 5, 8:38 pm, Alex Fanjul<alex.fan...@gmail.com> wrote: > >> Some thoughts and commentaries about major version: >> >> -My question came after thinking in Armin thread >> -Most of people seems to be convinced that there is no real reason >> (big issue) that couldn't be "avoidable enough" to need to realase a non >> backward compatible major version (so I figure out we have a strong >> framework in front) >> -Only real experience people (not like me) know if there are real >> motives to consider a non backward compatible major version >> -Many people say that web2py is so young to think in "big changes in >> code", but In case it would be real motives to do a "non backward >> compatible major version", and due to the youthfulness of the framework, >> wouldn't be better to do it as soon as possible and not after some years >> with many more users and applications online? >> -In case it would be real motives to do a "non backward compatible >> major version", wouldn't you prefer to adapt your application in return >> to have a better framework (maybe more secure, flexible, better writed, etc) >> >> These are only (and probably wrong) open thoughts and conjetures, so >> don't waste time in reply me... >> Alex F >> >> El 04/08/2009 23:08, waTR escribió: >> >> >> >> >>> I don't feel it is necessary to re-write anything yet. There is a lot >>> of good in it as it is. Don't just give up on it when you run into a >>> few difficulties. We are not talking about anything that won't be >>> addressed either. It is more of an issue of how it is addressed, and >>> for all the "weaknesses" in this framework, there are a hell of a lot >>> more strengths. >>> >> >>> Have patience, and don't forget this is a VERY young project. Also, >>> you may not agree with all the decisions all the time, but then no one >>> will in any framework. You can't please all the people all the time. >>> The key is to remember what brought you to this framework, and if that >>> still stands. All software has weaknesses, the question is whether it >>> is being dealt with or monitored. If it is, then one day in the near >>> future it will be addressed, but don't confuse speed of resolving all >>> problems brought up with quality solutions. Often the best solution >>> will require a lot of dialogue and a lot of analysis before >>> implementing. >>> >> >>> Also, not breaking backwards compatibility is a great rule to prevent >>> software from moving too fast. If the software breaks backwards >>> compatibility with every minor release, no one will use it because it >>> is not serious. If it breaks with every major release, no serious >>> project will use it because it would be too expensive to maintain. >>> Therefore, if all I have to do is use some added code in order to >>> solve the problem but preserve backward compatibility, then I am all >>> for it. If you have a small project that you can re-write in a day, >>> you won't care, but then I would not care about these minor issues if >>> that is all I needed it for. I am still following this framework >>> because I believe I can build something serious with it, not just a 5 >>> minute wiki AND I know I won't have to re-write everything once a >>> year. Breaking backwards compatibility is a very serious decision, and >>> I am very happy Massimo takes it VERY seriously. This attitude is what >>> will set this framework apart, and will make it deserve the title of >>> "Enterprise Framework". Otherwise, it is just another framework. >>> >> >>> If this project has to break backwards compatibility though, I would >>> hope it is done at the same time that it transitions to Python 3, as >>> that would take care of everything all at once. However, there is a >>> LOT of work to be done in assembling a list of issues and solutions >>> before that happens. So just be patient, and continue to use the >>> framework, that is how more issues can be discovered, and solutions >>> proposed. However, for today, there is no reason for even talking >>> about breaking backwards compatibility. >>> >> >>> On Aug 4, 12:00 pm, Fran<francisb...@googlemail.com> wrote: >>> >> >>>> On Aug 4, 7:30 pm, Pynthon<forumx...@gmail.com> wrote: >>>> >> >>>>> Yeah maybe a complete web2py 2 rewrite. With nice and better coding... >>>>> >> >>>> I believe this is a bad idea as we really don't want to break existing >>>> apps - this is a *key* strength of web2py& one many of it's adherents >>>> really value. This is what justifies the term 'Enterprise'. >>>> >> >>>> Many of the 'issues' are easy to solve without doing so& the rest are >>>> pretty much design decisions. >>>> They are seen as key strengths for some& key weaknesses for others. >>>> Let those who see them as strengths enjoy this& if others cannot live >>>> with what they see as weaknesses, let them choose from the many other >>>> frameworks out there. >>>> >> >>>> F >>>> >> -- >> Alejandro Fanjul Fdez. >> alex.fan...@gmail.comwww.mhproject.org >> > > > > -- Alejandro Fanjul Fdez. alex.fan...@gmail.com www.mhproject.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
