RE: [wtp-pmc] Proposal for Policy on non-API Code Deprecation

[Arthur Ryman <ryman@xxxxxxxxxx>]

Tim,

I made the edits and posted it on our
new Adopters page  (non-linked yet) [1]. I'd like to discuss this
at the status telecon tomorrow.

[1] http://www.eclipse.org/webtools/adopters/

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

"Tim Wagner" <twagner@xxxxxxx>
Sent by: wtp-pmc-bounces@xxxxxxxxxxx

12/01/2005 08:17 PM

Please respond to
"WTP PMC communications (including coordination and announcements and and Group discussions)" <wtp-pmc@xxxxxxxxxxx

To	"WTP PMC communications (including coordination, announcements,  and Group discussions)" <wtp-pmc@xxxxxxxxxxx>
cc
Subject	RE: [wtp-pmc] Proposal for Policy on non-API Code Deprecation

Two wording issues:

• “we are morally obligated to do so to the best of our ability” à Should we say “we will make a best effort attempt to do so”? I’m not sure how “morally obligated” will be interpreted.
• “. WTP will not apply the above deprecation policy to non-API code where API alternatives exist.” – We should be clear on what we’re stating here…if migration is mechanical, do we assume (i.e. force) adopters to migrate?

---

From: wtp-pmc-bounces@xxxxxxxxxxx
[mailto:wtp-pmc-bounces@xxxxxxxxxxx] On Behalf Of Lawrence Mandel
Sent: Wednesday, November 30, 2005 7:40 PM
To: WTP PMC communications (including coordination, announcements,
and Group discussions)
Subject: Re: [wtp-pmc] Proposal for Policy on non-API Code Deprecation
 

Arthur, 

Thanks for the clarifications, especially point 2. I'm fine with this so
long as we're clear to the WTP team that this is the strategy. I agree
that quality should be one of the top priorities in 1.5 (with an emphasis
on solving major problems - such as Java EE 5 support - early in the cycle!)
and I would still like to encourage teams to work on their API in 1.5 as
the sooner we define high quality API the sooner we can remove the requirement
to maintain internal structure.


Lawrence Mandel

Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814   Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx

Arthur Ryman/Toronto/IBM@IBMCA
Sent by: wtp-pmc-bounces@xxxxxxxxxxx

11/29/2005 01:24 PM

Please respond to
"WTP PMC communications (including coordination, announcements,  and Group discussions)"

To	"WTP PMC communications (including coordination, announcements,  and Group discussions)" <wtp-pmc@xxxxxxxxxxx>
cc
Subject	Re: [wtp-pmc] Proposal for Policy on non-API Code Deprecation

 

Lawrence, 

The time period between WTP 1.0 and WTP 1.5 is too short for adopters to
react to many changes. We therefore should evolve WTP in non-breaking ways
where possible. We still have ways to move forward in the next release,
e.g. 

1. Define API, but preserve the non-API code. For example, the API could
wrap the non-API code. 
2. Where preserving non-API code is very expensive, consult the scans to
determine who is impacted, review the proposed change with them, and provide
clear migration instructions.
3. Focus on fixing bugs and defer API work to 2.0. We do have a significant
bug backlog. Quality is also extremely important to adopters.

WTP will not be successful unless its adopters are successful. We'll have
more freedom to develop our API for 2.0.

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

Lawrence Mandel/Toronto/IBM@IBMCA
Sent by: wtp-pmc-bounces@xxxxxxxxxxx

11/29/2005 10:03 AM

Please respond to
"WTP PMC communications (including coordination, announcements,  and Group discussions)"

To	"WTP PMC communications (including coordination, announcements,  and Group discussions)" <wtp-pmc@xxxxxxxxxxx>
cc
Subject	Re: [wtp-pmc] Proposal for Policy on non-API Code Deprecation

 

With the small amount of API defined in WTP 1.0 I understand the need to
preserve non-API to allow for adoption of the platform. However I'm concerned
this blanket support we are proposing for adopters may hinder WTP development
as the team must maintain the internal structure, which may prove more
difficult than maintaining API, while developing new function or simply
evolving the structure of the code towards releasing API.

Lawrence Mandel

Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814   Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx

Arthur Ryman/Toronto/IBM@IBMCA
Sent by: wtp-pmc-bounces@xxxxxxxxxxx

11/28/2005 05:27 PM

Please respond to
"WTP PMC communications (including coordination, announcements,  and Group discussions)"

 

To	wtp-pmc@xxxxxxxxxxx
cc
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_______________________________________________
wtp-pmc mailing list
wtp-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-pmc_______________________________________________
wtp-pmc mailing list
wtp-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-pmc_______________________________________________
wtp-pmc mailing list
wtp-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-pmc_______________________________________________
wtp-pmc mailing list
wtp-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-pmc