On 5/2/06, me <[EMAIL PROTECTED]> wrote:
After having used the 1.1.1 release for a while, I attempted to use the 1.1.3 Snapshot with very disappointing results at compile time. Public classes and methods had moved and vanished wholesale. I looked back at the 1.1.1 code and did not see deprecation notices for the classes I noticed had changed.
Yes, it's unfortunately the case that huge packaging changes were made in order to be able to remove the dependencies between MyFaces Core and Tomahawk. However, trying to document all of these changes via deprecation would have been unmaintainable. Currently, MyFaces doesn't offer a "public api" other than the JSF spec classes in Myfaces-api.jar. You should never depend on classes in the Myfaces-impl. We don't officially support building components or extensions off of Tomahawk yet either -- ie, there's no "Tomahawk api" yet, but this is something we're working toward for the future. It'll very likely be called "MyFaces commons" and will be under an org.apache.myfaces.commons packaging structure (again, breaking the existing packaging structure). We made one attempt at this earlier this year, but it was premature and we had to back out of it. Once this happens, you'll be able to depend on backwards compatibility for things in the commons packaging, and AddResources is definitely one of things planned to be in that package. I agree that we need to track these things better. We've still got quite a ways to improve in several areas on release management, like opening JIRA issues on all changes and creating more accurate release notes.
I will add that it seems odd that project management issues are not also tracked in JIRA. From the big bold header on the JIRA home page, JIRA is for "Bug Tracking, Issue Tracking, & Project Management." Having a multiplicity of submission channels defeats the power of tracking, monitoring, searching, and consolidating provided by tools like JIRA.
Well, there's a difference between tracking finite tasks, bugs, and enhancements, and between discussing project policies, which is what you're bringing up here. The dev mailing exists precisely for discussing the project issues like this.
