Next step for the bundle

[gilles-g]

Hi everyone,

I open this issue to explain my problems and the solutions:

Because we can't maintain symfony 3.4 and 4.* version in the same code,

We need to create a new branch, only for 3.4, and called maybe sf_3_4, with green tests based on master.

For old project with SF 3.4, create a new branch 3.4, stay at tags v4.*

And for new project with SF 4.*, we will use master branch and we create a new tag v5 or v6.

But it's a long way to do! I don't have too much time for that...

If someone wants to help we needs mainteners.

• [x] Fix tests on master
• [x] Create new branch for 3.4 and let tags v4 on this branch
• [x] Start migrations with SF 5 and create new major tag v5

[94noni]

+1 for branches based on sf version

[MaciekGrabowski]

Hi guys, how it's looks like for SF5 now?

[bartmcleod]

Can we start by having branches named sf3, sf4 and sf5 ? That makes it easier to target a PR. For example, I would like to address some deprecation warnings with sf4 today, but I am not sure where to direct the PR. If we would have these branches, that would be clearer.

[94noni]

friendly ping @spike31 :) can you give us any visibility on this issue please?

there are some Prs ready for sf44 (https://github.com/lexik/LexikTranslationBundle/pull/361) and sf5 (https://github.com/lexik/LexikTranslationBundle/pull/367)

i would be pleased to help on this one, feel free to ping me!

[gilles-g]

Hi! @94noni @bartmcleod

I have created a new branch 3.4, big news :D

But the most important is to fix all tests on master branch first, maybe only for 3.4, then merge master in 3.4 and create tag for old projects.

So we need to update travis for 3.4 only! (I think it's more simple to fix tests for 3.4 and after switch on 4.4.)

Then after we could remove all "fix" code for SF 3.4, because master will be for SF 4.4 and 5.

[bartmcleod]

Hi @spike31 I have checked out the 3.4 branch to start making tests pass, but I did not get to testing it at all. I tried to run composer install first, but that fails on the dependency of the mongo extension. It seems it needs the mongo extension, which is deprecated and very hard to install, at least on my Mac. I could probaly use a Docker image, especially if you already have one ready to use. Also, is the deprecated extension really needed?

[gilles-g]

Hi @bartmcleod,

On a local machine, yes a dockerfile is the way to go and you can find some file on github.. Or you can fork the repository and use travis on your fork

I have started this fork for SF 3.4, and change for travis like this :

https://github.com/spike31/LexikTranslationBundle/blob/master/.travis.yml But tests failed if you check the travis page...And I don't know how to fix them

[bartmcleod]

Hi @spike31 "you can find some file on github", yes, which one? I have no experience with Travis, so I need a local docker image to be able to run at least composer install and get the dependencies right. On my host Mac, I have to play too many tricks and I am afraid to wreck it while installing deprecated stuff. I can try to create my own Dockerfile, but if you are already using one that works, I would rather use that one.

[bartmcleod]

Hi @spike31 I managed to create a docker environment for the 3.4 branch in which the tests pass. It wasn't exactly trivial, because it needs a MySQL and a Mongo database with a version < 4.2 (because of the deprecation of the 'group' command). The setup doesn't account for a custom mongo connection, but I made it so that it does now. I don't know much of Travis, so I don't know if my setup would help you in any way, but it might contain some clues as to how you could make it work. I will create a PR with my setup, so that other people who want to contribute to the 3.4 branch will have an easy setup experience if they use Docker. I am aware that my Dockerfile could be optimized and it might make certain people cringe, but it just a quick and dirty setup to create a development environment in which at least the tests pass, after composer install. The 4G of memory allowed for php are needed for composer.

[bartmcleod]

I wonder why travis is building for so many symfony versions. For the 3.4 branch, it should only build for 3.4 and maybe up to 4? Or is this a requirement for symfony bundles? Is it infered from composer.json? [edit]Ok, so these versions are listed in .travis.yml.

[bartmcleod]

I have experimented with a new tag 4.4 off the 4.4. branch and tried to require it inside an brand new Symfony 4.4 application. That is possible, but only if the composer.json of the sf project is modified to remove the explicit conflict found there and also only when we allow composer to remove/update anything that gets in the way. This results in the removal of 56 packages from the default installation. So I guess while all the tests pass in Travis, there is still work to do to make the 4.4 and the master branch play nicely with a default sf 4.4 installation. Possibly the symfony/symfony requirement needs to move to dev, but more changes may be necessary.