Compatibility with Symfony 4.0

[BenoitDuffez]

I would like to move forward and use Symfony 4, is there a reason why this bundle is only compatible with Symfony ~2.8 and ~3.0?

[shivas]

Reason is simple, symfony 4 is brand new and was not tested yet (with bundle), becoz it's major version release BC breaks are expected, that's why constraint was on major version. I'll look into support for Symfony 4

[BenoitDuffez]

That is perfectly fine, thanks for the answer.

Great if you have time to support Symfony 4. Looking forward to it! Thanks a lot!

[shivas]

I have just released version 3.0.0 that should be compatible with 3.4 and 4.0, can you try it out? composer should be able to figure out 3.0.0 as default goto version for 3.4 and 4.0 symfony projects

[Lionear]

I tried your bundle with Symfony 4 but it seems that the commands you provide are not available in the bin/console part of Symfony.

[shivas]

@Lionear how you created Symfony 4 project? Does bundle appear in bundles file?

[Lionear]

@shivas its a new Symfony 4 project and in the bundles.php I do see:

Shivas\VersioningBundle\ShivasVersioningBundle::class => ['all' => true],

[mdriessen]

The auto-registration of commands in bundles is deprecated in Symfony 3.4 and removed in Symfony 4. In the symfony4 branch of my fork this is fixed by registering the command manually. Also, all services are now private by default since they should be injected instead of fetched out of the container. To get rid of the deprecation notices in Symfony 3.4 I made the VersionsManager public.

However, in a pure Symfony 4 application my branch is still not working out of the box. That's why I haven't made a pull request yet. The app/config/parameters.yml (yaml) file has been removed and they now use .env files for configuring bundles with Symfony Flex.

@shivas What do you think is the best solution for this? Check if the parameters.yml file exists and use that, otherwise check if .env files are used? Or create a new version of this bundle that's only intended for Symfony 4? With a new version it also might be easier to make a Flex recipe and support autowiring / autoconfiguration. But I'm not that familiar with it yet.

[mdriessen]

I did some testing and updated my branch to work with Symfony 4. The only thing that needs to be configured manually is adding SHIVAS_APP_VERSION to the .env file, which can be automated with a Symfony Flex recipe. I also added a VersionExtension that adds the version string as a global to Twig so no manual configuration needed there either.

The only thing that isn't working yet is the Composer ScriptHandler, since the symfony-bin-dir variables are removed from the composer.json file. I'll have to look into how other bundles are handling this. Also, the readme file still needs to be updated.

The symfony4 branch in my repo only works for projects using Symfony Flex (Symfony 3.4 or 4). Probably the easiest way forward is using the 3.0 version of this bundle for Symfony Flex projects (.env file) and keep the 2.x version for Symfony without Flex (parameters.yml file)?

[shivas]

@mdriessen Thank you very much for PR, it's now merged and 3.1 version released (as 3.0 was not working)

[mdriessen]

I've submitted a PR for the Flex recipe: https://github.com/symfony/recipes-contrib/pull/295. Once that is merged the bundle should be auto configured when requiring the bundle.

[shivas]

👍

[mdriessen]

The recipe has been merged!

@Lionear Could you reinstall the bundle and check if version 3.1 is working for you?

[lushc]

I've noticed in my production environment that the version is never bumped because I don't deploy a .env file. I don't think you're actually meant to rely on its presence since the dotenv component docs mentions:

Symfony Dotenv should only be used in development/testing/staging environments. For production environments, use "real" environment variables.

This is also reiterated in the docs for configuring env vars in production. The framework bundle's front controller only loads this file as a last resort.

I'm not sure putenv would work since apparently it only lasts for the duration of the request, so I'm kinda out of ideas on how to both follow Symfony best practice and have an incrementing version number without going back to 2.x. Any ideas?

[mdriessen]

We use the Dotenv component in production because we have a lot of different configurations we need to load from the command line in the same project, so it never occurred to me not every production deployment has the .env file...

Maybe it's an idea the move the version number to a dedicated shivas_versioning.yaml configuration file? I wanted to avoid creating such a file since there is not much configuration needed for this bundle but I don't think there are many alternatives for storing the version number.

@shivas Maybe you have any other suggestions? I'll think about other solutions but for now you could use the VersionManager to get the version number each request from the service.

[lushc]

Thanks @mdriessen, using the VersionManager service is a great idea! I only need to read the version rarely (when capturing exceptions to report to Sentry) so that's a perfect workaround.

[mdriessen]

I tried the yaml file for storing the version number but that doesn't work the way I want. With the automatic configuration of the bump command there is no way to run it before the caches are cleared, so the old version number is stored in the cache. The .env file isn't cached so it didn't have that problem.

Another solution I'm thinking of trying is storing the version number as a constant in a Version class. The class can be updated with the bump command (I don't think this is an issue) and that way it's easy to retrieve the number from anywhere.

[mdriessen]

I'm almost done refactoring so the bundle doesn't need the .env file in production anymore (and even doesn't need the Flex recipe anymore). I still need to update the readme file and clean up some code. Then I will open a pull request and we can discuss the changes.

[shivas]

sure, thx @mdriessen for contributing stuff :+1:

[mdriessen]

@shivas Thanks for merging and releasing 3.1.3! The Flex recipe has been removed so I think we're all set.

I'm updating my projects to the new version (removing the bump command from composer, the application_version from parameters, using shivas_app_version in twig and using the assetic cache buster instead of appending the version string) and everything is looking good. 👍

[shivas]

:+1: closing this then, thanks for contribution