Jim Knutson wrote on 12/14/12 12:06:
> Pete Muir <pmuir_at_bleepbleep.org.uk> wrote on 12/13/2012 07:57:28 AM:
>> >> OPEN ISSUE: Should auto-discover be false by default for
>> beans.xml with version 1.1. This would mean that adding a beans.xml
>> would have no impact on discovery for 1.1 apps, however it is a
>> significant change from 1.0.
>> >
>> > No, please keep this in line with 1.0 behavior. If I think of the many
>> > lightweight migrated applications that rely on backward compatibility:
>> > Please don't change it!
>>
>> Note this would only be for beans.xml with the version attribute
>> updated to 1.1 so it wouldn't happen without a user actively doing
>> something. They could upgrade to the 1.1 schema, and set auto-
>> discover to all to keep CDI 1.0 behavior (we would make the auto-
>> discover attribute or element required).
>
> I worry about making behavior decisions based on "DD" versions. It would
> be better to make an explicit metadata declaration to change behavior.
> Changing a version is necessary for syntax (i.e. I need to specify
> additional metadata not supported in the current version, not for
> behavior. Using a version change to modify behavior is like programming
> with side effects. It will come back to bite you at some point.
I completely agree that, in general, this has been our policy.
However, we do have a few existing cases where semantic changes are tied
to the DD version. I don't like it, but in some cases it's believed to
be the lesser of the evils.
The question is whether that's the case here. Is the new behavior so much
better, and what we should've had from the beginning and what programmers
should prefer to use, that it would be excessive to require developers to
always specify it in their beans.xml?
If the new behavior means that developers will almost never need to create
a beans.xml (and that's been our goal), it might be acceptable to require
them to specify the new behavior explicitly when they do create a beans.xml.
I'd like to hear from a lot more EG members on this issue.