We should have been quicker in turning it into a public API as soon as
we realized its value for skin developers.
So I think that having a short grace period would be nice for our users
because it was our mistake for not making it public sooner.
- Jeanne
Matt Cooper wrote:
Hey guys,
Hi Matt, Adam,
well, it's your call - but there are quite a few people out there who
will have used this parameter already. Have fun answering their mails
;))
regards,
Martin
On 9/5/07, Matt Cooper [EMAIL PROTECTED] wrote:
I agree with Adam.
On 9/4/07, Adam Winer [EMAIL PROTECTED] wrote:
Why not keep the old one and the new one and just mark the old one as
deprecated for the next release? If both are set, the new one could
take precedence.
On 9/7/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi Matt, Adam,
well, it's your call - but there are quite a few people out there who
That's what I suggested, and Adam and Matt disagreed on. At least I
thought so ;)
One more hint why I think this would be appropriate: it shouldn't have
been a trinidadinternal parameter in the beginning, so I'd think we
shouldn't force users to take action on fixing a mistake we've been
making.
Hey guys,
Here's my thinking... Everything that contains trinidadinternal in its
name is not supported as an external API. By definition it is subject to
change without notice. If something is internal and valuable as a supported
API we are doing the right thing by exposing it as a public API.
I agree with Adam.
On 9/4/07, Adam Winer [EMAIL PROTECTED] wrote:
The old parameter was trinidadinternal, and therefore was
never officially supported. If we were changing from one
supported name to another, I'd agree that we should keep the
old name around, but supporting backwards
The old parameter was trinidadinternal, and therefore was
never officially supported. If we were changing from one
supported name to another, I'd agree that we should keep the
old name around, but supporting backwards compatibility
for anything trinidadinternal is a precedent I don't think we
Hi Danny,
eventually we could additionally support also the old name for the
configuration parameter, and only phase this out in a major release?
regards,
Martin
On 8/28/07, Danny Robinson [EMAIL PROTECTED] wrote:
In the hope of pre-empting some emails, be aware that the trunk has switched
In the hope of pre-empting some emails, be aware that the trunk has switched
to now use the following config setting for disabling skin compression.
org.apache.myfaces.trinidadinternal.DISABLE_CONTENT_COMPRESSION
became
org.apache.myfaces.trinidad.DISABLE_CONTENT_COMPRESSION
The docs and release
9 matches
Mail list logo
