Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] API Plan

Hi Tim, 
As you know, I am already involved in the server tooling with the
generic server tooling plugin as an implementor of the API. So I can
assist you with the implementation of the Tomcat plugins. And this way
I would not loose my edge as the first implementor of the API.
Gorkem Ercan

On Thu, 10 Feb 2005 10:03:14 -0500, Timothy Deboer <deboer@xxxxxxxxxx> wrote:
> Hi Arthur, 
> I've been working steadily on cleaning up API and have received some great
> help and advice from Jim. However, between the server tools framework,
> Tomcat tools, the TCP/IP monitor, and the Web browser, I am stretched very
> thin. This isn't an alarm yet, but we should discuss and create a plan for
> getting this done within the given schedule. If anyone from the community is
> interested in getting involved, I would appreciate help in any of these
> areas. 
> Thanks, 
> Tim deBoer
>  WebSphere Tools - IBM Canada Ltd.
>  (905) 413-3503  (tieline 969)
>  deboer@xxxxxxxxxx 
>  Arthur Ryman/Toronto/IBM@IBMCA 
> Sent by: wtp-dev-admin@xxxxxxxxxxx 
> 02/09/2005 06:04 PM 
> Please respond to
>  wtp-dev 
> To wtp-dev@xxxxxxxxxxx 
> cc Jim des Rivieres/Ottawa/IBM@IBMCA, John Wiegand <John_Wiegand@xxxxxxxxxx>
> Subject [wtp-dev] API Plan 
>  In an earlier note I recommended that we make M4 our API Freeze milestone.
> I'd like to clarify what this means and suggest how we should manage the API
> definition process. 
>  I got the following definition from Jeem: 
>  "We say that come API freeze, a component's API should be in shippable form
> and supportable in following releases. It many still need to be some
> polishing of the implementation underneath, but it should be just bug fixing
> and polishing. All specs and test suites should be in place. 
>  In Eclipse 3.0, we did the freezing in a couple of stages. We had an early
> cutoff for breaking API changes to pre-3.0 APIs. This kind of breaking API
> changes are always carefully reviewed and approved by PMC before proceeding.
> Most of the API changes are in fact non-breaking additions to existing APIs,
> or breaking changes to the new APIs that are still "settling". We expect
> developers to get all the API work done and in place before the API freeze.
> In practice, we get most of the way there, but there are still some API
> adjustments that are needed and we let them go in if there's a good reason
> to and they don't create problems. This is the slush stage of the API freeze
> process. 
>  As release draws near, a hard API freeze happens. We impose tight controls
> on all further API change by instituting a policy that proposed API changes
> of any sort (including trivial non-breaking ones) must be described by a
> detailed bug report and brought forward to the PMC. The PMC reviews these
> changes and weighs the potentially destabilizing effects of changing API at
> a late stage of the release cycle versus on the cost of leaving the API
> problem unaddressed.  FYI, in 3.0 we approved 50 API changes after the API
> freeze; only one was proposed but later withdrawn. All of them were minor." 
>  Here are the guidelines I suggest we follow: 
>  1. The most important reason to define an API is to provide stable
> interfaces to a "real" customer. Therefore, Rule #1 is that any WTP API must
> have at least one customer. The highest weight will be given to external
> customers. In priority order that means 1) Vendors that are planning to ship
> products based on WTP,  2) Eclipse projects that plan to use WTP, 3) other
> development projects that plan to use WTP, and 4) other WTP components that
> use WTP components. 
>  2. If the only customer for an API is another WTP component then we have
> some flexibility. If there is only one other WTP component that needs the 
> API, then we should look at merging the two components and defering the API.
> Remember that it is OK for plug-ins within a component to use internal
> packages. 
>  3. We need to do a great job on the key APIs and defer definition for
> others to future releases when the project has more users and contributors.
> An API is a big committment. Any WTP 1.0 API MUST be preserved in future
> releases, so it's best for the project if we are very selective about what
> APIs go into WTP 1.0. 
>  4. The M4 exit criteria for each API is: 
>         1) at least one customer has been identified and has reviewed the
> API, 
>         2) all Javadoc is complete, 
>         3) at least one JUnit test exists for each method in the API, 
>         4) a short overview document is complete. 
>  Note that it is enough for the JUnit to exist. It may fail if the API is
> not yet implemented. If these exit criteria are not met, then we either
> delay the milestone exit, or we pull the API. 
>  5. After M4, any change to an API must be approved by the Planning Group.
> The input to the Planning Group is: 
>         1) the component lead champions the change and has assessed the
> schedule impact, 
>         2) the Architecture Group has reviewed the change and supports it. 
>  Comments? 
>  Arthur Ryman,
>  Rational Desktop Tools Development
>  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
>  intranet: 

Gorkem Ercan

Back to the top