eZ Community » Blogs » Ivo Lukac » Is there a need for one more eZ...

By

Is there a need for one more eZ Publish Community Project release?

Wednesday 23 March 2016 11:13:12 pm

  • Currently 5 out of 5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Dear eZ Community,

I would like to use this opportunity and start a discussion about an important topic to get valuable feedback for the community board of which I recently became a member of.

Please take some time and read my long post from few weeks ago to get some context to the topic. Last week I took part in my first community board meeting together with the old members of the board where we discussed the topic too. After that I decided to start the discussion to see what the community thinks.

The main question is on what should community board and community as a whole focus on when it comes to eZ Publish community releases for supporting existing projects.

Current situation

With eZ Systems focusing on eZ Platform, eZ Studio and eZ Publish 5 Enterprise, the community project with legacy stack was left as is. The last version was 2014.11 which is almost year and a half old. Focusing on new generation is good but existing projects with legacy code still need some support. We at Netgen made our own version which we called 2014.12 which we treat as a maintenance release for bug fixes, security patches and similar. We decided to open source it and quickly found out that other partners have done the same thing internally. Some already switched to our version and more will use it surely if we move it to some community git repo. We would like to do this too.

But this effort solves just one part of the problem. There are many projects out there that have still a lot of legacy code, either on front end or on back office side. Those projects are currently stuck on the last community version 2014.11 (very few use the 2014.12) or with the maintained latest eZ Publish Enterprise 5.4.*. This situation doesn't help the migration of these projects to eZ Platform. Those projects might have parts of the front end refactored to the new stack but some features are not possible to refactor on those versions (e.g. eZ Find). All customisations of the back office are also limited to legacy coding.

For some of those project a complete push to eZ Platform + eZ Studio might be possible, but there are certainly lot of them for which this is not an option yet. They need gradual migration possibilities so they don’t lose features they had already but can progress with refactoring as new stack capabilities emerge. Those projects could use eZ Platform + legacy bridge but this is starting to be problematic more and more with each new breaking change that will come.

Two options

In my opinion, which I expressed in the last community board, we as a community need to push 2 important agenda:

  • make it easy for new developers to start using the eZ Platform (and not bother them with legacy)
  • make it possible to gradually migrate existing projects to new stack and not let them stuck without options

As the resources are scarce we need to focus on the most important things. For the existing projects it is to create a community release which will be maintained by community, steered by the community board and endorsed by eZ Systems. The question is what approach to take. There are two main options that I can see:

1. introduce a successor to 2014.12 (might be version 2014.13) which will not be only maintenance release but should be used to backport certain features from eZ Platform. It could become base for eZ Publish 5.4.* minor releases so the work could be joined with eZ Engineering

2. create a new community edition (might be e.g. version 2016.02) which will use eZ Platform with legacy bridge and the old administration. The main effort for the community would be to solve the breaking changes on the legacy kernel side so that the old admin is usable.

Just to be clear, both options have more or less short term lifecycle. It would be unrealistic to expect that we can do a lot of back-porting or fixing every breaking changes, but if its even just till 2016 Q3, this is great. It would be almost 2 years newer than version 2014.11 so existing projects will have a lot of new features from eZ Platform to implement and the new admin UI to adopt.

There are pros and cons for both options:

- first option sounds more stable and eZ engineering might help more. Foundation is already set with our 2014.12 variant. The main question is how to choose which features to backport.

- second option will give more new features in eZ Platform and will offer easier adoption of the new admin UI over time. The main question is how easy would be to fix the breaking changes in the legacy kernel.

There are, of course, many more questions, but I am sure we as a community could tackle so that our projects and clients benefit from it.

Give feedback

Please, give your feedback so that we in the community board can take optimal action.  

Is there a need for one more eZ Publish Community Project release? If yes, what option would you prefer and why? 

Every opinion matters.

Proudly Developed with from