Plone Release Manager Wichert Akkerman sent the following email to the plone-developers list today, outlining the schedule for Plone 3.1, which will end with a final release in March 2008.  Plone 3.1 will be a small release with a few new features and no major architectural changes.  It will be a seamless and safe migration from Plone 3.0.

In coordination with the new framework team I am happy to be able to announce the timeline for the next Plone feature-release: Plone 3.1. The release process for 3.1 has very specific goals:

Safe changes only: since this is a minor release which should not destabilize Plone 3.x only changes that are risk-free will be considered. This means that no or very minimal migration steps are allowed, everything has to be properly tested, documentation has to be in order and the user interface has to be finalized. This also means that 3.1 will be based on the 3.0 codebase: Plone trunk has far too many major changes already.

Do not overload the framework team: the deadlines are fast and strict, so making it easy for them to rest proposals is important. The best way to do that is to create a buildout based on the latest Plone 3.0.x release and include only the changes relevant for that proposal.

Quick release schedule: we do not want to take 9 months to get this release it. This means that all proposals have to be completely done and polished in order to be acceptable. The migrations, if any, have to be in place and working, there have to be working tests and the user interface must be complete.

This is the timeline for 3.1:

  2007-12-14 : PLIPs for all features have to be finished and submitted

  2007-12-21 : framework team gives verdict on PLIPs only, not an implementation

  2008-01-19 : review bundles have to be submitted to the framework team

  2008-02-02 : framework team completes reviews

  2008-02-08 : 3.1 pre-release tagged

  2008-02-11 : 3.1 pre-release with installers released

  2008-02-15 : 3.1 release candidate tagged

  2008-02-18 : 3.1 release candidate with installers released

  2008-02-29 : 3.1 final tagged

  2008-03-02 : 3.1 final with installers released

Note that there is a change from the procedure we used for Plone 3.0: there is now an extra PLIP-review step. This has been added to allow us to check of a proposal is not too invasive or for some other reason undesirable for 3.1. That makes sure that nobody will be trying very hard to make a deadline only to hear that their work is not going to be considered.

As you can see this is an ambitious schedule. This means that we have to be very strict in what will be accepted and what won't. There is no shame in missing a deadline - we are all busy people and sometimes a deadline is just not attainable. Anything that does not make it in can be reconsidered for 3.2 or 4.0.

On a whim (it was planned 2 days ago), some of the Seattle Crew decided to get together this weekend and sprint.  The goal is ambitious, but simple: to fix a bunch of bugs and add futures to increment the releases of our Plone/Salesforce.com integration products.  I'm hosting in good ol' Ballard, Washington.

Pictures of jonstahl, healingKnee, jessesnyder, brianfive, and davisagli below:

This is a fun post recognizing the role of open source software and breaking routines in learning new programming patterns and paradigms.

7 Reasons I switched back to PHP after 2 years on Rails

Rails was an amazing teacher. I loved it’s “do exactly as I say” paint-by-numbers framework that taught me some great guidelines. I love Ruby for making me really understand OOP. God, Ruby is so beautiful. I love you, Ruby. But the main reason that any programmer learning any new language thinks the new language is SO much better than the old one is because he’s a better programmer now!

This story articulated an idea that I have been thinking about for a while - the ways in which developers working on open source software enter into an educational relationship with the software and the community (sometimes indirectly, mediated through the code).

I have often appreciated all that Plone has taught me about the domain of content management, component architectures, extensible software design, internationalization, test driven development, responsible release management, etc etc. I know that it has taught me well since when I walk up to new pieces of complex software like Sakai or Drupal the concepts are familiar and often isomorphic. I can vouch that exposure to Plone has helped designers I know with stretch their CSS skills, improve the accessibility of their sites, and more cleanly separate presentation from logic.

I have also made the case that for an organization to work on software in isolation is bit like having a conversation with yourself. At first you might arrive at some new insights, but its really hard to learn anything new in a hermetically-sealed vacuum chamber. The software world transforms so quickly that it is a Sisyphean task for any one person or organization to track. Joining a community, even if it is through the indirect, intermediary object of code, is a great way to continue learning and stay on top of emerging trends. The notion that learning happens through dialog is an old one; the notion that working with open source software is a form a dialog with the authors is a bit less obvious.

My main critique of Derek's post is that he doesn't explicitly acknowledge the fact that Rails is open source, which is precisely what enabled him to learn so much from the framework. This isn't just a matter of attribution, it has practical implications for being able to continue learning new tricks over time.  If he had realized that Rails-the-software embodied the knowledge of the Rails-the-community, he might not have been so quick to venture off and write his very own framework. I am not arguing that he should have steered clear of php, but he does not explain why he decided to roll his own framework as opposed to joining forces with Cake or another existing php framework, or at least using an existing php templating system. With a more explicit understanding of the origins of the knowledge that Rails-the-software captures, he may have appreciated the potential future gains of remaining part of some community.

While it is possible to learn something from proprietary frameworks, "learning" is fundamentally about the open exchange of knowledge and meaning, which are values intrinsic to F/OSS. While you can learn something from a .NET api, you can't step through the entire stack of software in the debugger. Perhaps more importantly, the cultural tendencies on an open project support constructionist poking and prodding (dare I say, hacking?).