[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[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