>> I'd like to ask the dev people behind the 1.x branch what their >> thoughts are, I assume not everyone took part in the above discussion. >> Is there a lot term commitment to the 1.x branch? Should the 1.x >> branch get closer and closer to the 2.x or not necessarily and should >> it evolve on its own? Will/should tg fork? >> >> Any thoughts I'd appreciate very much! > > Well, I'm not a 1.x developer, but I play one on TV. > > Seriously though, I've been talking to them a lot about this, and I > think that we all have a clear commitment to maintaining the 1.x > branch as a supported environment. > > There are also a few people committed to enhancing TG 1.x via the 1.5 > branch and beyond. > > At the moment the changes that are going into 1.5 bring it closer to > tg2 than 1.1 will be, and that is a clear benifit for a set of users > who are too wedded to cherrypy to easily move to 2.0 right now. > > The situation becomes less clear when/if the API's begin to diverge > rather than converge. And we all know that is something that may > happen at some point. And at that point a fork would make sense. > The think I want to be clear on is that Ken and others have done a lot > of good work on the 1.5 branch, and there's a lot that's valuable to > real users, so we definitely want to support that. > > At the same time if the TurboGears project is going to continue and be > successful we absolutely have to present a clear picture to new users > about the future, and at this point 2.0 has been that declared future > for quite a while. And, from my discussion with Ken, and others, we > all still agree that it's the future of the TG brand. > > So, ultimately we can and will support whatever the 1.5+ community > wants to do, but we have to be careful about how we manage the > TurboGears brand. > > There will likely have to be big decisions about this in the future, > with a friendly fork as a real possibility, but we'll make those > decisions when and if the time comes. And we're pretty solidly in > agreement that 1.5 itself will be "tg2 like" enought that it provides > a useful stepping stone for some users, and therefore will make good > sense as an official TurboGears release. > > To be clear 1.5 can, and will do more than be a stepping stone to 2.0, > but if it's going to have the turbogears name it cannot do less. > And we will provide a clear strategy for folks to migrate directly > from 1.1 to 2.0, so 1.5 will not be a required stepping stone. > > As for 1.6, who knows? We'll cross that bridge when we come to it. > After all, we'll know more then than we do now, and we'll probably > make better decisions because of that knowledge. > > And we have developed a bit of a shared consensus for how those > decisions will be made -- when and if 1.x and 2.x start to diverge > rather than converge, we need to think about rebranding. This is no > bad thing, as it shows that the TurboGears philosophy will have proven > itself in the framework ideas marketplace. But it's not something we > should jump into either. > > The core message that we should be communicating is this: > > * TG2 is the future of TurboGears > > * TG as a community will focus more in 2009 than we did in 2008, and > that focus will be on 2.x > > * TG 1.x will continue to be supported throughout 2009 and beyond > > For those who want the nuances, we can also say: > > * With that said there's still room for people who want to work on 1.5. > > * For those with lots of CherryPy dependent code 1.5 may be a nice way > forward > > * Eventually the constraints of the TurboGears brand may lead to a > friendly fork off of the 1.5 branch > > * We're all working together, and all care about making life better > for users, so everything will work out as it should. > > --Mark Ramm
Thanks a lot Mark! The above sounds perfectly reasonable and I'm sure will suit at least 95% of the user base (it's certainly great news to me :)). Thanks again for communicating these issues so clearly. Let me just add one thing: for me, and perhaps others too, the major stumbling block in front of upgrading to 2.x from 1.x is ORM support and not cherrypy or anything else. I started developing using sqlobject and as you can imagine sqlobject code is sprinkled around just about everywhere. The majority of the business logic is ORM-related code. Since 2.x doesn't have support for sqlobject I can't easily upgrade regardless of what stepping stones are provided in 1.1 and/or 1.5. I don't depend on cherrypy or other parts of the framework too much that would make the upgrade difficult, the sole difficulty is the ORM. It's clear that the tg team can not make the transition from sqlobject to sqlalchemy any easier, so I'm definitely not arguing for that. What I'm saying is that if many users are in the same boat (transition to 2.x from 1.x would be easy from a framework point of view, but hard from an ORM point of view because of the sqlobject - sqlalchemy transition) then perhaps not so much emphasis needs to go into creating stepping stones such as 1.1 and 1.5. But maybe many other users are not ORM limited, they perhaps really need stepping stones for the framework itself. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
