Symfony 4.0 has been released together with PHP 7.2 last month (see #9009 for PHP 7.2 support status), so here's the plan:
Sylius 1.0 won't officially support Symfony 4.0 - it will stay with Symfony 3.3-3.4. The reasoning behind this is that we can only rely on Symfony 3.3 features there, so that if something has got deprecated in Symfony 3.4 and there was a forward compatibility layer provided for that, then we still can't use that without breaking backwards compatibility with Symfony 3.3. And some of our components / bundles requires ^3.2 Symfony components.
Sylius 1.1 will require Symfony 3.4 - support for Symfony 4.0 will come as soon as we solve all the deprecations in our and vendors' code.
The only missing step to start fighting deprecations is to set up Travis to include Symfony 4.0 jobs, which I'll have taken care of in this year :)
pamil
All 27 comments
https://github.com/SymfonyTest/symfony-bundle-test maybe this can help with testing the bundles (that don't have have any additional tests) for multiple Symfony versions.
sstok
on 30 Jan 2018
@sstok yeah, we have similar setup for the application tests (requiring symfony/symfony in a specific version) but for the packages tests we would need to require Symfony components in a specific version.
Eg. User package:
https://github.com/Sylius/Sylius/blob/cf9493076f3b59557be80efc967e240bb99b991d/src/Sylius/Component/User/composer.json#L30-L37
Then we should require symfony/security in a given version, but abstain from requiring symfony/polyfill-mbstring in that version too, as it has different release cycle.
pamil
on 30 Jan 2018
Symfony introduced the concept of https://github.com/symfony/lts to prevent getting "old" versions,
but @dunglas (sorry for pinging) created https://github.com/dunglas/symfony-lock as an alternative to lock to one specific major version (ensuring all components/bundles/bridges are of the same version and no 4.0 is installed when locking to 3.x), especially for CI.
sstok
on 30 Jan 2018
Major locks would work here, I'm still thinking how to test the changes between minor versions (https://github.com/dunglas/symfony-lock/issues/3), as a project this big usually hits a regression or a few even when upgrading a minor. This way we could test Symfony 3.4 and 4.0 in every build and include another Symfony versions (like 3.3 for Sylius 1.0 or 4.1 for Sylius 1.1+) in nightly build.
pamil
on 30 Jan 2018
You could introduce your own lock package that has a very strict conflict for minor versions :) (really tricky though!)
sstok
on 30 Jan 2018
I also accept PRs on this package :) It would be nice to create new branches for all major version (it can also be scripted to support all versions).
dunglas
on 30 Jan 2018
All right, I've created a project to keep track of Symfony 4.0 related issues in Sylius and everywhere else: https://github.com/Sylius/Sylius/projects/4
pamil
on 14 Feb 2018
The overall plan is to support Symfony 4.x by Sylius 1.2 release, which is scheduled at late May. The first thing to do right now is to make our external dependencies support Symfony 4 and have them tagged as a stable release and perform packages tests for both Symfony versions on our Travis.
pamil
on 14 Feb 2018
I just discovered your project, which looks great. But I am building a Symfony 4 app and would like to "borrow" only some of the Sylius bundles. Is this possible? Or do I have to wait until the 1.2 release?
Tech-Nomad
on 12 Mar 2018
@Tech-Nomad we do not support Symfony 4 in any of our bundles yet, I can make them available (^1.2@dev would install master branch), so that you can install these and fix some stuff there to get it working on Symfony 4 (if needed). The other way is to wait for 1.2 release, but some help with that would be welcomed :)
pamil
on 13 Mar 2018
Just have opened #9254.
pamil
on 13 Mar 2018
Thanx for the info! Unfortunately I just 've started to develop with Symfony, so I don't think I could participate much in any Bundle Development
Tech-Nomad
on 18 Mar 2018
@Tech-Nomad yeah sure, no problem, hope we'll support Symfony 4 soon :)
pamil
on 4 Apr 2018
@Tech-Nomad Sylius packages with version ^1.2@dev should be installable with Symfony 4.0+ and should work fine (although it's not a stable release yet).
pamil
on 1 May 2018
Symfony 4 is supported on Sylius/Sylius (#9429), the only missing parts are Sylius/Sylius-Standard, Sylius/PluginSkeleton and an upgrade guide (v1.1.x -> v1.2.0, together with Symfony 4 related changes).
pamil
on 26 May 2018
It's done!
pamil
on 4 Jun 2018
How to install Sylius with sfymfony 4 ? The installer is install symfony 3.4.
cansozeri
on 5 Jun 2018
@cansozeri v1.2.0-BETA features Symfony 4 support, stable v1.2.0 release is coming at the beginning of the next week.
pamil
on 6 Jun 2018
@pamil Then with v1.2 composer create-project sylius/sylius-standard this installer is gonna create a symfony 4 project, is it right ?
What do you think about the new approach of symfony 4 called - bundle-less ? Sylius 1.2 is going to follow this ??
cansozeri
on 6 Jun 2018
@pamil In Symfony versions prior to 4.0, it was recommended to organize your own application code using bundles. This is no longer recommended and bundles should only be used to share code and features between multiple applications.
Do you think to change the way for sylius ??
cansozeri
on 11 Jul 2018
@cansozeri I think you misunderstood the new best practices from symfony 3 about the bundles structure. To simplify, it was saying "do not create a bundle if your bundle can't live alone", and it was mainly for apps not for frameworks. Sylius bundles are relevant because they can be separated and used alone.
NB: if I remember correctly, this best practice was introduced just after symfony 2 misleading docs, people were creating useless bundles in their own app.
wadjeroudi
on 12 Jul 2018
@wadjeroudi Thank you for your response. I am a Laravel guy and new to symfony 馃槉 But as I readings, I think your point is not true for symfony 4.
There is autowired and autoregistered services in symfony4.
Symfony 4 does not have ANY bundles in src/anymore. All files now lives just in src/ directory (and have App/ namespace by default)
Bundle inheritance mechanisms are deprecated in 3.4 and were removed in 4.0.
So am I wrong that, sylius can do exactly same things without bundles. With Flex, there is no need config and other stuff too.
cansozeri
on 12 Jul 2018
@cansozeri , as told you by @wadjeroudi , the bundle structure is deprecated only for the application in its own.
This means that in your application src you have to use the namespaces to divide the code in logical chunks: so, if you want a structure based on features, while once you used bundles, you now use namsepaces and a proper configuration of Symfony (via tags or configuring the folders in which the various kind of files reside: entities, controllers, listeners/subscribers, ecc.)
But for third-party code (as the one provided by Sylius), you will continue to use bundles.
The main purpose of Flex is to simplify the integration of third-party bundles in your application.
Bundles, tipically, require some sort of configuration: this part is automated by Flex that modify the relvant files on its own on installation and removal of bundles.
So, in the end: the bundles are discouraged only when you want to use them to divide your own code (and so having a UserBundle, a CartBundle, a ProductBundle, ecc...).
But if you want to use the code of your UserBundle in two different application, then, technically, you are going to create a third-party bundle, and so you create a UserBundle that is installable via composer and configurable through Flex.
About inheritance, it is not supported as it was, but it still exist: you can override any part of THIRD-PARTY bundle: templates, translations, controllers, ecc...
Aerendir
on 12 Jul 2018
@Aerendir Thank you for your answer, I understand clearly. Sylius is using flex too or going to use in the feature I think.
cansozeri
on 12 Jul 2018
@cansozeri the recommendation is for applications, Sylius itself is both an application and a library, so it doesn't really apply to us, because we also provide standalone packages.
pamil
on 12 Jul 2018
What cansozeri is trying to say is that in fact the majority of the sylius bundle have dependence on other sylius bundle. But they are not different composer bundle, so this is a bit strange.
Ofc this make impossible to decouple the app, becouse you can't remove unwantend dependence.
So, why not just remove the bundle word, and use it only for truly decoupled one?
In the flex way this would mean having sylius/UIbundle etc, instead of only sylius/sylius as composer dep
Bonobomagno
on 30 Aug 2018
@Bonobomagno Thank you for clarification 馃槉
cansozeri
on 30 Aug 2018
Related issues
xleliberty
路
3Comments
reyostallenberg
路
3Comments
crbelaus
路
3Comments
loic425
路
3Comments
inssein
路
3Comments
Most helpful comment
The overall plan is to support Symfony 4.x by Sylius 1.2 release, which is scheduled at late May. The first thing to do right now is to make our external dependencies support Symfony 4 and have them tagged as a stable release and perform packages tests for both Symfony versions on our Travis.