[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[wtp-pmc] Agenda for November 28, 2005 telecon
|
Agenda:
- 1.0 rollout plan
- EMO will drive press release
activity around this.
- Plan for coordinated blog
activity week of release.
- Other plans?
- 1.0 Status
- RC1 progress
- Defect outlook / adoption
readiness
- API status
- API Support Statement (see
Arthur’s email, attached)
- Requirements update
- Architecture update
- JSF project status update
- Additional topics
Naci sent his regrets for this meeting.
|
From: wtp-pmc-bounces@xxxxxxxxxxx on behalf of Arthur Ryman
[ryman@xxxxxxxxxx]
Sent: Monday, November 28, 2005 2:28
PM
To: wtp-pmc@xxxxxxxxxxx
Subject: [wtp-pmc] Proposal for
Policy on non-API Code Deprecation
PMC
Members,
As I
discussed previously, I think we need to adopt a policy that helps WTP adopters
evolve as we roll out our API. Here is an updated proposal that incorporates
feedback from David: WTP 1.0
will not publish API for all functions that adopters may require. Adopters
therefore may elect to use non-API code. Although we are not technically
obligated to preserve the non-API code in WTP 1.5, we are morally obligated to
do so to the best of our ability. We should gracefully deprecate the non-API
code for one or two releases before completely removing it and forcing adopters
to migrate. Since there is a lot of non-API code, we need to focus on the
portions of it that adopters are actually using. Furthermore, we need to give
our developers tools to determine if they are potentially breaking any adopter.
Avoiding breakage in important, frequently used non-API code will also be good
practice for us in preparation for evolving our API code in a non-breaking way.
Here are the main points:
1. WTP will provide to adopters a simple build
tool that can use to scan their code and generate a report of their usage of WTP
code that can be attached to a bugzilla report. The reports will be purely
statistical (usage counts) and not reveal any details about the vendor's code in
order to preserve privacy. Vendors who volunteerily opt in to this reporting
process will benefit from our efforts to reduce potential breakage in their code
as WTP evolves its code.
2. WTP will provide to its developers a build
tool that scans our code and detects breakage in both API and non-API code.
Known API breakage will be considered a "blocker" P1 bug. Breakage in non-API
code will be flagged if there is significant adopter usage of it, in which case
an effort will be made to preserve the non-API code, or provide migration
documentation. The techniques used to evolve API code will be applied to the
important non-API code on a best efforts basis. In cases where breakage is
unavoidable, affected adopters will be notified.
3. When feasible, WTP
will deprecate important non-API code for a period of at least one major
release. Adopters will be encouraged to migrate to the new version between
releases.
4. WTP will review the non-API usage reports for cases where
adopters are not using available API code and we will inform adopters that API
alternatives exist and that they should migrate to them. WTP will not apply the
above deprecation policy to non-API code where API alternatives exist.
5. WTP will review the non-API usage reports and use that information to
prioritise the evolution of non-API code to API code. Non-API code that has high
adopter usage will be given the highest priority.
Any more comments? If
this is agreeable, we should collect the non-API usage reports in
mid-January.
Arthur Ryman,
IBM Software Group,
Rational Division
blog:
http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL
969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL
969-4920
mobile: +1-416-939-5063, text:
4169395063@xxxxxxx