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