Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop support for unsupported dependencies in v3 #1548

Open
tacman opened this issue Jan 2, 2024 · 2 comments
Open

Drop support for unsupported dependencies in v3 #1548

tacman opened this issue Jan 2, 2024 · 2 comments

Comments

@tacman
Copy link
Contributor

tacman commented Jan 2, 2024

Let's drop all support for anything EOL in version 3. In fact, I'd like to see V3 only support Symfony 6.4 || ^7.0, and skip 5.4 (since anyone on 5.4 can still use v2).

Twig 2 just published its last release, so in V3 I think we should just support V3 of twig.

Ditto for old versions of PHP.

Is 3.0 of this bundle okay to use in a production environment, at least for all the v2 features?

@dbu
Copy link
Member

dbu commented Jan 2, 2024

i agree, we should cleanup up a lot here.

version 3.x did not diverge all that much from 2.x yet, so i don't expect bugs or broken things.

but i hope we can do some more cleanups that might lead to BC breaks - so using the 3.x branch might be bumpy when upgrading dependencies.

notably with issues like #1523 and many people with problems with paths, i would love to cleanup how we handle the paths (and fix the naming to be easier to understand). it should be simple to understand when its about storing the source image somewhere, when about storing a cached image and when its the url to load the image in a browser.
i also hope that we can ditch some of the code for supporting various storage solutions in favor of just league/flysystem for everything beyond the local filesystem. or maybe even hard depend on flysystem and use it for local files too.

@tacman
Copy link
Contributor Author

tacman commented Jan 3, 2024

Well, that'd be great. As I mentioned elsewhere, dropping OneUp would make documentation much easier.

I think my situation is probably pretty common -- I develop with a local filesystem, and occasionally with S3, then I deploy to production with S3. This works well once it's set up, but setting it up the first time was confusing for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants