Is that bump really needed? AFAIK, we try to avoid as much as possible to bump dependencies (see#53160 (comment))

(same for othercomposer.json files)

FrameworkBundle often bumps the min version instead of trying to support multiple versions of the service definitions, for simplicity.
This is different for other package, which can be reused outside the fullstack framework and for which supporting compatibility with 2 different major versions of Symfony reduces the risk of dependency hell in those projects (the lower level the package is, the more useful this is).

Thank you.

I've bumped version on FrameworkBundle and HttpKernel. I have reverted the other packages and make sure they (still) support both 6.4 and 7.2.

I think that we can add the non-legacy version as well

defining the new signature of the constructor as beingnew Serializer([], $encoders, $chainNormalizer, $chainDenormalizer) looks weird to me. It don't think the array as first argument should be kept in the new signature

alternatively, we could keep the current constructor signature, making the ChainNormalizer and ChainDenormalizer internal implementation details, as done for the ChainEncoder and ChainDecoder (for which we classify them as being encoders, decoders or both inside the constructor). As most implementations are implementing both interfaces in the same class, it allows passing a single list in instantiation, making the configuration easier

Btw, this would mean that the chain classes would not need to implement the*aware interfaces (as the injection would be handled by the Serializer on each registered class)

Yeah. I dont like the current signature too.

I want to have a signature like:

newSerializer($encoders,$normalizer,$denormalizer);// ornewSerializer($normalizer,$denormalizer,$encoders);

Should I immediately go to that signature or should we change it in SF8?

On your separate topic of making theChain* classes an implementation detail.. That was an earlier version of the PR, but we decided against that to make theSerializer more simple. See#52900 (comment)

Treating them like$encoders is a valid idea. However, you have 1-3 encoders MAX. But you may have 100+ normalizers/denormalizers. So I think it makes more sense to keep them separate and give the developer more control.

Should I immediately go to that signature or should we change it in SF8?

Youmust support the new signature immediately. Otherwise doing the change in 8.0 will be forbidden as it would be a BC break without migration path.

On your separate topic of making the Chain* classes an implementation detail.. That was an earlier version of the PR, but we decided against that to make the Serializer more simple. See#52900 (comment)

That comment was actually suggesting toalso change the way encoders are injected (we should avoid making 2 successive signature changes on the constructor, as that would be a pain to have 2 deprecated signatures to support in the BC layer)

Treating them like $encoders is a valid idea. However, you have 1-3 encoders MAX. But you may have 100+ normalizers/denormalizers. So I think it makes more sense to keep them separate and give the developer more control.

but then, you make it more likely to have nested ChainNormalizer instance, making it necessary to be 100% sure about the reliability ofgetSupportedTypes for instance (my suggestedreturn ['*' => false]` will be reliable, even though it might not be the most optimized one).

this logic looks wrong to me. As this compiler pass is registered as a before-optimization pass, the definition class might not be known yet as a class name:

• when using ChildDefinition, it can benull (if the class will be inherited from the parent), but this doesnot mean that skipping the registration of the service is the valid processing (btw, this is a BC break in case someone uses a ChildDefinition to configure a normalizer today)
• if a service definition uses a parameter in the class name (which is supported since 2.0), the parameter is not yet resolved at that point, requiring to resolve it explicitly

if we make the ChainNormalizer available publicly, this is flawed as it breaks when nesting a ChainNormalizer inside another ChainNormalizer (the normalizers inside the inner ChainNormalizer won't get access to the main normalizer supporting everything)

Would a solution be to haveChainNormalizer also implement theNormalizerAwareInterface?