[Framework-Team] Re: Re: Release roadmap for 3.0

Martin Aspeli optilude at gmx.net
Wed May 10 22:21:26 UTC 2006


On Wed, 10 May 2006 21:05:04 +0100, whit  
<d.w.morriss at gmail.com> wrote:

> /me dons grumpy old former FWT member hat
>
> remember, all that SoC stuff has to have bundles and be approved by you
> guys.  No implementing proposals after the fact.  That's about the only
> standing rule for this team.

I agree entirely.

> So if you are looking at this sort of
> schedule, likely almost none of the SoC stuff will go in until until a
> later 3.x release.

And, as I just replied to Rocky, this isn't something we can just take  
lightly. It may not matter to you or me, but it matters a hell of a lot to  
the guy who is debating whether to put the effort in to deliver some  
killer feature. If the battle is lost before it's even begun, he won't  
bother, and it'll more likely be 4.5 than 3.5 before it gets picked up  
again (there's a reason why versioning is PLIP #8 and we have 157 PLIPs  
spanning several years).

> Also, 3.0 really should be just one louder than
> 2.5, regardless of the number.

I don't agree with this - and I don't think this was the intention with  
the UI release/framework release split. As I recall it explained to me,  
the plan was that .0 releases would be the big bang - once a year, we  
release a new version of Plone with impressive new features, where we  
progress and make some hard decisions about what we may need to break or  
strongly deprecate to move Plone-the-product forward.

Then, we let the dust settle. We don't introduce anything that rocks the  
boat too much, but we enable a .5 release to improve the framework, to  
give developers better tools to build upon, to ensure consistency and  
currency with the lower parts of the stack (e.g. new Zope/CMF versions).  
These versions are easier to migrate to, they are about safety and  
stability. And it may take until the subsequent .5 until some of the users  
of the *previous* .0 are willing or able to upgrade.

I'd argue that Plone-the-product, as far as end users is concerned, hasn't  
really progressed very much since Plone 2.0. We still don't have  
versioning, locking, staging, taxonomy/categorisation in anything more  
sophisticated than a folder, we still have a very static UI, with many  
slow page reloads, we have a fairly inflexible portlets infrastructure  
that makes it awkward to make the CMS personalisable. And some of the cool  
things we've talked about for years that real users really love, such as  
contextualised help and actions, or UI improvements to selection widgets  
and folder navigation, are still unrealised.

Meanwhile, there *is* competition. The big name right now is Alfresco, and  
they are *killing* us on many aspects. We still have a stronger community,  
we still have a better business model, we still have a better UI (though  
their's ain't that bad). The other big one is (slightly awkardly) Rails,  
where all the innovation in web UI seems to be happening. If Plone is to  
survive, it needs to stay ahead of the curve, to be sexy and intuitive. It  
also needs to avoid having too many red crosses in the feature matrices.

So, the step from 2.1 to 2.5 was a natural evolution, to incorporate Zope  
3 much more into our stack, which in turn has unleashed a lot of power  
that we can use to drive the more real use cases. It was a joy to see how  
much power we could get out of this discussing implementations of PLIPs in  
Norway.

But 2.5 is a whisper to our end users, to the people who review Plone in  
magazines and online journals. About the only innovations I can think of  
off-hand are drag-and-drop folder re-ordering, placeful workflow (which I  
fear most people won't need), and maybe the history tab making a  
re-appearance for a poor-mans audit trail. PAS? Views? Users don't care  
(developers do of course). If 3.0 is no louder than that, we'll get maybe  
two or three of the Archipelago PLIPs in place, and Plone will make what I  
fear is another release that goes the world quietly by, and then community  
gets tired of the release frenzy, settles down to do other things, and  
very little happens.

Take a look at http://plone.org/products/plone/releases/3.0

How great would it be if Plone could have even the majority of those  
features? Let's not give up before we've begun.

> I would argue that the proposal freeze *is* the feature freeze *is* the
> last date that the framework team accepts bundles for review.

 From that point of view, sure, though there is a much greater informal  
period before that (which has arguably already begun) where we work out  
what we would like people to work on and what to push for. The process of  
even starting on a bundle isn't random, we have a pretty strong list of  
features we really want Plone to have at 3.0, that have something to do  
with how we want to market Plone and how we want to ensure it's not being  
left in the dust by the competition.

Martin

-- 
"You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006




More information about the Framework-Team mailing list