Symfony3 support?

[dkarlovi]

I'm asking a Question

Please submit your question via the forum http://www.akeneo.com/forums/forum/questions/

This link is broken so I'll risk asking here anyhow: do you plan on supporting Symfony 3?

I understand your decision from #3419 (and why you've not yet done it), but that paired with fixed versions in composer.json and Symfony 2.7 only makes it quite a challenge to use your (what looks like) quite high-quality components inside an existing and new Symfony apps.

[nidup]

Hi @dkarlovi

Thank you for raising the broken links, we recently migrated our forum, I just fixed them :+1:

Regarding the whole application, we stick to LTS versions of Symfony http://symfony.com/doc/current/contributing/community/releases.html#schedule

FYI, we do this because we maintain our Enterprise Edition 18 months, this version is based on Community Edition which requires Symfony, and we don't bump our dependencies for already released versions (only security patches of our dependencies in worst case).

I'm very interested to discuss about using these components outside the Akeneo PIM full stack, we recently discussed this topic with @gplanchat who uses the batch component as standalone.

For instance, this component has very few adherence with Symfony component and, even if the main composer of the stack remain sticky with Symfony 2.7 or 2.8, it may be usable with Symfony 3 (as the migration path of symfony between 2.8 and 3.x is pretty smooth).

What components would you use outside of the PIM?

[dkarlovi]

Hi @nidup,

I see, LTS Symfony is a way to go in that scenario, I'd do exactly the same in your shoes. :)

We're planning a backoffice type API app which would a kind of "custom PaaS" with a very specific scope. One of the entity types to handle is products and Akeneo's product repository seems to fit the bill really well here.

On the other hand, products are not the only entity type and we'd need to implement most f them ourselves, probably using API Platform. Using Akeneo full stack here would super-charge our products handling, but might hinder implementing the rest as we'd need to fit everything to match Akeneo's overall functionality, it would be a big gamble on our part.

So my line of reasoning was to use Akeneo only as a "headless products repository" and wrap it with other repositories behind a common API interface.

Thanks for the reply, closing this.

[nidup]

Hi @dkarlovi

Very interesting use case, thx for sharing :)

FYI, in our technical product roadmap, we'd love to be able to have a light distribution of the Akeneo PIM stack, ie, be able to boot a light PIM kernel without UI by decoupling more properly the backend and the frontend parts.

We also plan to work on a more complete web rest API (read/write), I can't give you precise ETA for now but we're currently studying it.

Cheers.