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