Release policy: Define the Symfony Components targets about contributions-symfony-consolebridge HOT 8 CLOSED

Hello :-),

What does it imply?

from contributions-symfony-consolebridge.

@Hywan Almost nothing at a code level as Symfony team works hard to maintain BC as much as possible.

Things to keep in mind are :

• LTS will certainly be more used
• Standard releases will provide latest cool features

from contributions-symfony-consolebridge.

So this is a “new cool features” vs. “LTS, used by more people” choice? My experience would go to LTS because the idea is to have a lot of users. It will stil be possible to have a branch for new features. Thoughts?

from contributions-symfony-consolebridge.

@Hywan everything is possible :)

I think that working with two running branches, each one targeting a different version of Symfony, will be a pain (backports, merges, ...)

IMHO, the best approach would be to target the LTS releases in the master, but also let it support non-LTS releases via some version sniffing and other checks.

Doing so, we will always be fully compatible with LTS and support, at least, the next non-LTS release. This will be easy to handle at a code level but we will have to clearly communicate our intentions on this point.

from contributions-symfony-consolebridge.

+1 for me.

from contributions-symfony-consolebridge.

I tweaked the travis build to test against several symfony/console versions:
https://travis-ci.org/hoaproject/Contributions-Symfony-ConsoleBridge

from contributions-symfony-consolebridge.

https://github.com/hoaproject/Contributions-Symfony-ConsoleBridge/blob/master/composer.json#L28

from contributions-symfony-consolebridge.

👍

from contributions-symfony-consolebridge.