I'm not being precious but it seems that this thread has been "hijacked" to discuss branches when I really want feedback re my proposal :-)
On Nov 11, 3:20 pm, achipa <[EMAIL PROTECTED]> wrote: > Usually another person is appointed as maintainer for those cases. As > no extensive changes are likely to happen in the 'oldstable' branch > it's just basically someone who is trusted and familiar with web2py > enough to do bugfixes and backports, which is a lot less effort than > doing spearhead development which is usually done by the original > author or team. It's like Linus always working on the actual/dev > kernel and Alan Cox, Andrew Morton or whoever maintining the > previously released stable branches. > > On Nov 11, 2:36 pm, carlo <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
