[Framework-Team] Plone 5 - rough roadmap
limi at plone.org
Mon Mar 15 09:13:30 UTC 2010
2010/3/12 Hanno Schlichting <hanno at hannosch.eu>
> On Fri, Mar 12, 2010 at 5:39 PM, Laurence Rowe <l at lrowe.co.uk> wrote:
> > On 12 March 2010 15:07, Hanno Schlichting <hanno at hannosch.eu> wrote:
> >> Currently listed for Plone 4.x are things like:
> > ...
> >> - Well formed, valid XHTML (as a foundation for easier theming via xdv)
> That's really good to hear. Though I think "semantic HTML" or
> "sensible ids/classes" to identify elements in pages is what I had in
> mind with this point. Well besides the valid XHTML which is a
> requirement for Chameleon as well.
It's also likely that we'll transition to using HTML5 (the XHTML-compatible
"phrasing", ie. HTML5, but close your tags), and Deco as a layout engine
will be much happier if we do a revamp of the existing HTML structure. It's
quite messy in parts from the 8+ years in production, and while it has held
up well, it's time to adjust to how the web has evolved since then,
especially with focus on our upcoming theming capabilities.
Also, while on the subject of release management, it would be possible to
split up these major new technologies in smaller releases, but we'd have to
look at which things should land together. E.g. xdv and Deco should likely
be in the same release —but don't *have* to — whereas Dexterity might be a
requirement for tiles/blocks. (I'm inventing dependencies here, so no need
to point out that any of these assumptions aren't correct ;)
We could also take a page from how Firefox is looking to change their
release management strategy, ie. landing stuff that has only infrastructural
impact in a 4.x release (out-of-process plugins in FF's example, which will
land in the 3.6 series, for Plone 4.x, it could be something like WSGI). Of
course, that's what we're already doing, but pushing the less risky parts
that were previously considered only for Plone 5 might be a good approach,
and reduce risk. Landing too much at once in Plone 5 is definitely a real
risk, as is a too-long release cycle for Plone 5. So evaluating each of the
things we land in Plone 5 for possible inclusion in a future 4.x release is
probably a good tactic.
I'd love to see a shorter release cycle for Plone 5, but as usual, it's hard
to determine, and I don't think the currently suggested estimates are
unreasonable. I think an increased focus on "Tech Preview" releases (ie.
what alpha used to mean :P ) could provide useful checkpoints for people to
rally around when it comes to development. We shouldn't underestimate the
power of self-imposed deadlines, I think it was used well in the Plone 4
release cycle, and even if Plone 5 is a release with a longer release cycle,
we should try to do several checkpoints along the way to avoid landing too
much at once, and get stuff out there for people to test in carefully
managed projects, similar to what Jarn and others have been doing for Plone
Alexander Limi · http://limi.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Framework-Team