Handling Transition between 4.x and 5.x

1. ezp5 transition from client project perspective
technical, when to use ezp5, when to use legacy. when to switch
in ezp5, still possible to run legacy as before.
will be in 5.0 and 5.1 at least
Some performance issues with context switching symfony/legacy
recommendation: use either legacy completely, or ezp5. avoid mixing.
use reverse proxy caching, which is well supported
for "serious use": starting 5.1 (or "middle release" 5.0.x)
missing: image variations, some data types (field types), ezstarrating
ezp5 is completely rewritten, no copy paste
Storage engine interface, currently just one that can interface with legacy. In-
memory used for (abstraction) tests.
all existing extensions use legacy kernel, and admin is still legacy.
cookbook for making ezp5 extensions is in the works
mix and match: you can write a legacy extension with twig templates
using ezp5 features in legacy is easier than the opposite
From ezp5, you want to reduce time spent on legacy code, but ezp5 is still not
fully ready - legacy will be needed still for some things (like image
variations)
be aware of terminology changes:
data types -> field types
node -> location
class -> type
content object -> content
some 10x of theses. someone started a dictionary?
look at your feature requirements - if it fits symfony well, go that route
extension architecture: designed to be more obivious/consistent/transparent
interfaces show you how things should be done
you can replace/extend pretty much anything in ezp5
site accesses work more or less like before. we have siteaccess groups now.
we have reduced the amount of available settings, to make things easier.
ezp5 is a symfony app with legacy inside
support: new and old stack. some parts of the new stack that are either not used
by ezp, or still experimental, may not be supported. this will be clear by the
release.
new: rest api uses the new stack
demo design allows "all" features, but performance is not good yet
you have to make sure you cache your things properly - each controller must send
correct headers, so that varnish etc can cache them: etags
standard http caching
http purge will be supported
subrequests (renders) replaces fetches. each can be cached. etags can be
controlled by you, so expiration strategy can be whatever you want
you have to learn the new caching system - it is different, but not more
complicated.