[jsr-314-open] [C036-ElInResources] Vote favors DefaultToOptOut

[Jim Driscoll]

On 10/2/09 2:56 PM, Lincoln Baxter, III wrote:
>>     but once we allow it,
>>     we can't "unallow" it when a better method comes along.
>
> I disagree. I think that backwards compatibility has pluses and minuses,
> but we should not rule out removing features that don't make sense
> anymore, or changing features that break something in order to achieve a
> greater good for the future of JSF. It should be done sparingly, but is
> sometimes necessary.

I had this same discussion with Dan, earlier.

Let's leave aside the wisdom of backward incompatible changes: 
Regardless of how you (or I) feel about backward compatibility, Sun 
(along with the majority of the EC, including companies like Oracle and 
IBM) have always been firmly in the "no backward incompatible change" camp.

That means that you should *always* assume that backward incompatible 
changes will be disallowed by forces outside the control of the JSF EG. 
Don't put anything in that you aren't willing to live with permanently.

Jim