I totally share your thoughts, it should be great to have a web2py 3000 as a new branch. The problem is whether Massimo has enough resources to support two branches of his creature.
carlo On 11 Nov, 13:50, achipa <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
