search

lexik / LexikTranslationBundle

This Symfony bundle allow to import translation files content into the database and provide a GUI to edit translations.
MIT License
422 stars 259 forks source link

Updated for Symfony 5.0 and 5.2 #378

Closed bartmcleod closed 3 years ago

bartmcleod commented 3 years ago

try out, to see if travis wants to build for 5.0 and 5.2. Symfony is now in the 4.4 branch.

gilles-g commented 3 years ago

You can compare with the JwtBundle or FormFilterBundle maybe ;)

bartmcleod commented 3 years ago

Well on my way with this one I think, testing it locally. I will try to mark it as WIP.

bartmcleod commented 3 years ago

@spike31 Since this now passes for Symfony 5, we could merge it, although it is not perfect. I would say we delete the 5.0 branch (I accidentally pushed the same changes there), we do not need a separate 5.0 branch right now, just a tag. Before we merge, we should tag 4.4 or similar or continue the versioning with v4.0.15?

bartmcleod commented 3 years ago

And after that, there is a lot of low hanging fruit in using new php features throughout the code.

gilles-g commented 3 years ago

@bartmcleod

Hi, I forgot to answerd to your question. But you have already create a release, but you make a mistake.

Because you introduce BC with this release.

Developpers who uses the bundle with a requirement like 4.0.* or ^4..0, they want to continu to use the tag with 4.* with never BC. Do you understand?

We have to create a new major tag, 5.0.0 for the future of this bundle. And 4.* will be for the past ;)

So I will remove the release, and let you create the new release.

And the convention for tags in this bundle is to prefix with the letter "v", look here https://packagist.org/packages/lexik/translation-bundle

Ping me if you need help

Merci

bartmcleod commented 3 years ago

Sorry for the inconvenience I caused. I hoped with the release to create a 'last-know-good' fixation for Symfony 4.. What is causing the BC break exactly? For the current PR (this one) I will create a v5. tag, that is clear. But for current master, should we not still have a v4.4.0 tag at least?

gilles-g commented 3 years ago

For the current master, we can create a release for SF 4.4, but it will be the first and last release for this version of Symfony...

Because in this PR, composer.json required SF 5.0

Do you understand what I mean? once the branch is merged, we will no longer be able to make any corrections for SF 4.4

bartmcleod commented 3 years ago

@spike31 I am not sure about this, but I have a different understand about tags. We now have a 3.4 and a 4.4 branch and master (and also a 5.0 branch that we should delete, but I did not see that option - different story).

If we would checkout the 3.4 branch locally and we would create a tag, say v3.4.19 just as an example and we would then push that tag, in my understanding that would result in the code from the 3.4 branch from the time when the tag was created. Similar for the 4.4 branch that we have now (currently the same code as master). After merging the current PR and releasing that as v5.0.0, we would still be able to create tags based on the 4.4 branch and base releases on it. Am I wrong about that?

See here for example: https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/managing-tags#:~:text=About%20tags%20in%20GitHub%20Desktop,-GitHub%20Desktop%20allows&text=You%20can%20use%20a%20tag,repository%20with%20the%20associated%20commit.

gilles-g commented 3 years ago

Ah ok, I didn't know for the branch 4.4!

Ok, so you can create release for each branch that you want...just be careful with BC.

OK for v5!

bartmcleod commented 3 years ago

Ok! I will merge this now and try tonight how it works with release and using it in an actual sf 5 application.