Do we need to define facets as API - what attributes, behavior should be considered API? Possibly similar to plugin extension points where everything considered API. Let's discuss possible changes we can make to our policy documents for clarification
We may need to define our policy on API deprecation or altering API behavior in both the current and maintenance releases. Eclipse API Deprecation Policy
After some good discussion, we decided some clarification is needed for WTP's API policy, and Chuck will send an initial draft to the PMC list for further discussion. Neil pointed out a good statement(describing the "entire" API) from the platform is located here summary below: "Note that the API (Application Programming Interface) is the entire public programming surface of the framework, thus it includes not only Java classes, packages, and interfaces, but also extension points, file formats, generated meta-data, and even objects that are passed through to internal packages."
Continue polling - re-evaluate by M4 - Should we put a stake in the ground mandating when we need to see some progress in educating our committers? - investigate a subproject that could "pilot" a git repo feeding into our overall PDE build - More discussion on CVS - GIT transition - should replace CVS feature for feature - Platform HAS put a stake in the ground.... CVS Retirement bug (Target: December 21, 2012)
Many small problems found - subtle changes in behavior - tracking with "wtp4x" in whiteboard. Tracking query
More details to come...
webtool.website Progress from tracking bug
Progress moving WTP 3.4 builds "officially" to 4.2 platform as the default. Carl is finished promoting our Juno M2 build, and is 4.2 based. He has also changed the order and frequency of both 3.8 and 4.2 builds. EMF is fixing the problem with 3.8 based builds shortly after M2 is declared.
Back to meeting list.
Please send any additions or corrections to Chuck Bridgham.
Back to the top