The line must be drawn otherwise after a while it will be harder (and messier) to make any progress because of all the backwards compatibility issues (see Microsoft), especially in a relase often type OSS project. The simplest and cleanest solution, done in many OSS projects is well-planned deprecation and two stable branches. One is the backwards compatible one (1.x in web2py case) and the other is not and has all the revolutionary ideas (let's call that 2.x). The trick is not to ditch 1.x right after you release 2.0 but to backport from the 2.x branch what is backportable and of course do bugfixes for 1.x, and have a well defined guide for migration from 1.x to 2.x. I agree you must not *force* people to upgrade, but saying that everything has to be backwards compatible across *all versions* is like saying we don't want do significant improvements and introduce drastically new technologies. Also, the longer 'stretch' of backwards compatibility exists, the harder it will to eventually introduce change (think DOS and win32 api, x86 assembler). Apache and the linux kernel had two stable branches, python will also have something similar (plus the transitional 2.6), so I guess it is a valid option.
On Nov 11, 1:32 pm, billf <[EMAIL PROTECTED]> wrote: > Seeker > > I think you have a good point but, playing devil's advocate, if you > want to establish yourself in an enterprise section of the market it > is a disadvantage to give users the ultimatum "if you want X then you > have to change Y". > > Perhaps, an alternative is to deprecate methods and classes so that > users are warned and tend to rewrite over a period of time so that > "old" code withers. I have seen this work with Java but I don't know > if it would have the same effect with Python. > > In the context of my proposal, perhaps SQLFORM would be marked > @deprecated with users guided towards Resource. > > On Nov 11, 12:23 pm, seeker <[EMAIL PROTECTED]> wrote: > > > Just a thought: > > (Please don't shoot me for mentioning this; I say it with Web2Py's > > best interest in mind) > > > In general I have been very much in favour of Massimo's philosophy of > > maintaining backward compatibility. > > However, part of me wonders whether this is an indefinitely > > sustainable idea. I am concerned that, in the long run, it will cause > > the project to stagnate. > > > Would it not perhaps be a better idea to follow the example of Ubuntu > > (and others). They regularly release new versions for all who wish to > > remain current; but every now and then they release 'special' versions > > which are supported for a reasonably long period of time. > > > In general technology (and ideas) develop so fast that very few > > systems would require really long term compatibility to be maintained > > and the benefit of evolution may just outweigh the benefits of not > > evolving at all. > > > Please note that I am by no means advocating a radical re-design of > > Web2Py with every release though. > > > Like I said; just a thought. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
