Thats something users will have to find in the 3.0 upgrade file, so no deprecation warning in earlier 2.x versions. Is that expected? (No idea how one could warn users, though...)

@mpdude Not sure if there is a way to deprecate protected property the only thing came to my mind is to add a note in UPGRADE-2.8.md.

There's a way but you won't like it. Implement __get() which returns only the property required but also throws a deprecation notice.

@iltar no it won't work as expected, the locale will be considered as public property.

The question is what the "Symfony standard way" of doing this looks like.

Does this BC break really add a value to the codebase? I mean, is it really worth it to take the risk of breaking applications / libraries relying on this $locale property?

@hhamon making locale private can reduce the risk to use an invalid locale see setLocale and also I would prefer the public methods instead (setLocale, getLocale).

ping @symfony/deciders

and given that we added validations of invalid locales to avoid a security issue, forcing to go through the setter to update it seems logical to me.

👍

I'm 👍 given that it usually doesn't make sense to make properties protected when there are public getters/setters also defined. There is no point it creating 2 extension points, esp. when it's security related.

👍

Thank you @aitboudad.