[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[wtp-pmc] Agenda for Sept. 20th telecon
|
Agenda:
- Community update
- Administrative
issues
- Committer vote for
Konstantin
- Charter mods to be
brought before the board (see attached)
- Contribution
questionnaire policy
- Requirements update
- Architecture update
and status of “flexible project” planning
- 0.7.1 status
- 1.0 planning
- Verify M9 component
plans updated
- M8 status
- IP log work needs
to begin (release review is now only two months away…)
- Other open 1.0
issues?
- JSF update
- API declaration and
deprecation policy (see attached copy of Arthur’s email)
|
From: wtp-pmc-bounces@xxxxxxxxxxx on behalf of Arthur Ryman
[ryman@xxxxxxxxxx]
Sent: Tuesday, September 20, 2005 5:54
AM
To: wtp-pmc@xxxxxxxxxxx
Subject: [wtp-pmc] Proposal for
Policy on non-API Code Deprecation
PMC
Members, As I discussed last week, I
think we need to adopt a policy that helps WTP adopters evolve as we roll out
our API. In WTP 1.0 we will not have a complete API and will therefore be
forcing adopters 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 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 a
relatively painless way to determine if they are potentially breaking any
adopter. Avoiding breakage in 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. WTP will also provide adopters an easy way to
send their usage reports to us. 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
non-API 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. No API breakage will be tolerated. 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. 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. 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.
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
Attachment:
mods.zip
Description: mods.zip
