I peaked into my crystal ball and came up with a couple of statements that reflect my own personal opinion. So here is one possible scenario for the future:
- The Plone 3 series will see major releases up until 3.4 or 3.5 in a roughly six to nine month iteration and stretch into 2010.
- Plone 3 will see support for Python 2.5 and 2.6 in Plone 3.4 while staying backwards compatible with Python 2.4.
- Plone 4 final will be released in early 2010.
- Plone 4 will recommend Python 2.6 and might be backward compatible with 2.5.
- Plone 4 will see multiple 4.x releases in the same way 3.x did. These will continue throughout 2010 and 2011.
- If a Python 2.7 is released during the lifetime of Plone 4.x, support for it will be added.
- Plone 5 will run on Python 3 and see a release in 2011 or 2012.
11 comments:
I'd prefer a more aggressive timetable.
Frameworks always have a migration lag, because they must wait for underlying libraries and packages to be migrated first. But your suggested scenario is too lackadaisical. Good gosh, Python 2.5 is *already* old news, and Plone/Zope haven't even made it there yet!
Remember that the newer Pythons have bona fide improvements in bug fixes, optimizations, and new features. The migration leap will be painful, but there's a real benefit from doing it.
As a general rule, I like "Be no more than one minor revision behind."
That Python 2.6 and 3 exist simultaneously muddies up that rule a bit. But, I wish Plone and Zope were available on Python 2.5 now. If Plone 4 releases in 2010, I say it ought to run on Python 3. Waiting until "2011 or 2012" for a Plone that runs on Python 3 would be nuts, IMHO.
Sounds good to me. I think it's important for us to use as much of the __future__ imports of 2.6 in 4.x to ease our transition.
For a start, we should move zope. and plone. packages to having py3k distributions (preferably compatible source).
@John: I wish many things as well. But the constrains we live under don't let us do whatever we'd wish for.
Python 3 support is definitely not feasible for Plone 4. The amount of rewrites this will require on all the levels of our stack is just too big. Plone isn't a small well-tested application with a sane complete Unicode I/O story - far from it.
Moving to the latest Python 2.x release for the Plone 4 line will allow us to gradually upgrade our codebase and give all our add-ons a chance to do the same. Making this possible while there is no support beyond Python 2.4 today is already pushing it. We pay the price for being framework bound on the one side and being used as an extensible application on the other side.
John, that's interesting. I read Hanno's blog entry and thought "Plone on Python 3 in 2011? That's an aggressive timetable!"
Plone on Python 3 in 2011 means we got about 2 to 3 years to port over Zope 3 and Zope 2 to Python 3. Let's hope we'll have enough volunteers to do the job in that time frame, and don't get too much difficulty coordinating everybody and juggling branches... Hanno's post made me hopeful the Plone people are going to help out in a big way with this. :)
@Martijn: I see this roadmap as aggressive but realistic. The main focus is on moving Plone into a position where it might have a choice of using Python 3 for Plone 5.
But this entirely depends on the amount of volunteer forces working on all the different framework levels, as well as on our own codebase. I cannot guarantee that ;)
Hanno: Sounds good.
John: Python 3 will not be ready to port to until 2010, third-party libraries need porting, etc. I don't think Zope itself will run on Python 3 until 2011. Plone 5 on Python 3 for 2011 and 2012 sounds like an optimistic, but possible, time frame.
In recent weeks I've had some moments to check up on the state of the trunk branch of Plone and since then I've recommended several people to start using it as their consulting/solution platform. It's got a good vibe, starts up in seconds and performs much better in general than the 3.x series.
Here's a timetable I'd like to see:
April 1st: Plone 4 – alpha preview release
October 1st: Plone 4 - beta release
January 1st, 2009: Plone 4 – final
I'd like for Plone 4 to get wildly unstable, lose the CMF, Archetypes and fifty pounds, then regain stability. We should try to implement the "Plone 4 user interface vision", retain the concepts that are solid whilst seriously clean up the dirty fundamentals.
As for Python 3.0, I don't think it's essential in any way. Python 2.6 will have a lot of goodies and it'll be a faster interpreter in a long time than the 3.x series.
Meanwhile, we should try and get rid of encoded strings throughout the codebase since this eventually will be the major evolutionary difficulty.
As for Plone 3.x, I think it's a great series––let's leave it close to how it is and switch our development focus to the new series. If many developers are interested in keeping development going, well good for them, and good for Plone 3.x. That's the beauty of the free open-source community: It's driven by interest.
Personally, I'd probably contribute some to a Plone 4 which would see the light of day before Iceland joins the European Union.
[This is John DeRosa. Hanno, did you change your blog's setup? Now, I can't post a comment without registering with Google or Blogger, or using OpenID. But yesterday, I could. Now I gotta log in with my old OpenID server, which I don't use very often. Oh well.)
@Hanno, Martijn, regebro: Some more thinking...
There has been a Python 2.x release every 1.5 -- 2 years. Guido expects the 3.x series to do .x releases "much sooner" than what was customary for the 2.x series.
This suggests that in January 2011, we'll be at Python 3.2 or 3.3. In January 2012, we'll be at Python 3.3 or 3.4.
Running on Python 3.0 in 2011 or 2012 may at first sound great. But then there's the sobering realization that Python 3.0 will at that time be an old revision! (Python 3.0 will not just be old, but be officially "ancient," in 2012...)
Django today runs on Python 2.5. In the django-developers mailing list, James Bennett proposed that Django 1.4 will support only Python 2.6, with a H2 CY10 target. The thinking is that they'll support Python 3 then or shortly thereafter, and can drop 2.6 support when convenient. This may change of course, but it's the thinking de jour.
Plone's time delay to Python 3 is a tad longer than Django's (and therefore, any CMSs built on Django), but maybe not by much if it could happen in early 2011.
Today, FWIW, the latest Drupal uses the latest PHP.
I apologize if my response was brusque. Hanno asked "what do you think," and I answered with my gut reaction. I did not mean to impugn the good folks who are working on the Python migration! If it sounds that way, I apologize for it.
My concern is that a longer delay to new Python versions provides a opening for Plone's competition to do some negative marketing. And of course, Plone and Zope won't benefit from the improvements in the latest Python. While db access dominates, there are many goodies in the latest Python, and bugfixes, and optimizations, that would be great to have in Plone/Zope's foundation.
I'm trying to say, and I guess I'm not being good at saying it, that this schedule, which may be great when considering the amount of work involved and the people available to do it, doesn't look speedy "on paper" when compared to other frameworks' migration plans.
FWIW, I'm interested in helping with the migration, but I'm still a Plone noob. I hope to be confident enough in six months to volunteer my services and help out where I can.
@malthe: The Python 3.x interpreter is slower than the 2.6 interpreter now, true. But we shouldn't expect that to still be true of the 3.x interpreter in two years.
John,
There are some fundamental misunderstandings here, I think. Let me try to give some more detail:
• When Hanno says "Python 3", he means Python 3.x. It's unlikely that the difference between Python 3.0 and 3.2/3.3 will be large enough that it will be problematic. The only reason we got into trouble with Zope and Python 2.5/2.6 was Zope's use of RestrictedPython, which we're (hopefully!) moving away from anyway.
• Plone trunk (what will become 4.0) is running on Python 2.6, today. Doesn't help for deploying a site for the general public, but if you really need it, it can be done.
• It's quite obvious that you are unfamiliar with the benefits of Python 3.0 as well as the general code base architecture of our stack, which is understandable. Among other things, both Plone and Zope depend on third-party libraries that have their own porting schedules.
• This is Hanno's "best guess", and I think it's great that someone sets the expectations and tries to get to a realistic time frame. If we can beat that timeframe, great!
• A lot of things will become available in Python 2.7, 2.8 etc using the __future__ namespace, which means we can start using the Python 3 syntax and some of its features, and clean up Plone along the way.
• The comparisons with Django and PHP are entirely inappropriate. They have a fraction of the code, and a fraction of the functionality out of the box. They are frameworks and programming languages, respectively — Plone is none of those, it's an application. (and a kick-ass community, but they are more easily upgraded ;)
• That being said, I'm all for crazy experiments — if someone has the energy to do an attempt to convert it all, i.e. do a quick pass to get us closer to a realistic estimate, that's something I would love to see.
…and Malthe, I think you wrote 2009 when you meant 2010. If Plone 4.0 final is released on January 1st 2009, we'd better get going — that's in three weeks! ;)
Duh, strike my comment about PHP. I mis-read that part, sorry. It's still an inappropriate comparison, since PHP has never broken backwards compatibility like Python 3 does. And Drupal is also a fraction of the code/functionality of Plone.
Yes, Plones timefram is slower than Djangos, because Plone is a CMS while Django is a webframework. Without knowing anything about Djangos plans for Python 3, I'd expect Django and Zope 3 to run on Python 3 at about the same time, which is 1-2 years from now.
But then we need to port Zope2, and then we can make the first wild attempts to port Plone to see where we at, as per Limi's request. :)
Post a Comment