[Bundles] Update best practices to use Symfony Flex and do not favor any CI tool

[wouterj]

Fixes #10361

I think it's better to not show a complete Travis CI config, but instead document the intentions behind it. This way, everyone can implement them on their favorite CI tool.

Meanwhile, I removed the symfony/lts usage instead of the now recommended SYMFONY_REQUIRE env var.

[noniagriconomie]

Is it still worth documenting v3.4?

Also for the travis config file, is it possible to use the langage toggle config feature php/xml/yaml but instead use it for toggling between for example github actions, travis, etc ?

[dbu]

Suggested change

	Thus, a bundle support PHP 7.3, 7.4 and 8.0, and Symfony 3.4 and 4.x should
	Thus, a bundle supporting PHP 7.3, 7.4 and 8.0, and Symfony 3.4, 4.x and 5.x should

listing explicit versions is prone to be outdated after a while, but i think this is about the example, so getting outdated is ok.

[dbu]

thanks for the update. i find it a pitty to completely drop the example config file, it is quite nice to see a full example (also great to quickstart a repo). can we preserve that file somehow somewhere? i was thinking of putting it in a gist, but that is a bit fragile and tied to a personal account. linking a concrete example in a popular OSS bundle is also prone to not work at some point. could we have a non-rst file in the doc that can be downloaded?

[dbu]

Suggested change

	* All supported major Symfony versions (e.g. both ``3.x`` and ``4.x`` if
	* All supported major Symfony versions (e.g. both ``4.x`` and ``5.x`` if

[javiereguiluz]

I disagree with this 😐 I'd love to provide a realistic example that readers can copy+paste to test their bundles.

[wouterj]

Alright, what do we do then? Given Travis changes its paid plan, does it makes sense to replace the Travis config with GitHub actions? (as it'll probably be a more common use-case for new bundles starting now)

Or as, suggested by @noniagriconomie, do we want tabs? The "issue" with tabs is that we need to explicitly add them to the Sphinx config.

[wouterj]

Something else I was just thinking: what about creating a template repository for new bundles? That would include the README, GitHub actions config, main directories, etc.

[javiereguiluz]

That could be a nice idea. I feel like the "onboarding" for bundle authors has too much friction. We could have a make:bundle maker, a template repository, better docs about how to create a bundle and support multiple Symfony versions, how to create a "fake" Symfony app to functional test the bundle, etc.

[javiereguiluz]

Thank you Wouter!