| Looks good. Thanks John. Jeff
On 2009-11-03, at 10:07 AM, John Arthorne wrote:
Thanks for the comments Martin. Based
on all the feedback and our discussions in the PMC calls, I have updated
the draft to use only time periods instead of a fixed number of releases.
I.e., deprecated API will stick around for two years rather than two releases.
This avoids the problem of putting too much emphasis on the release "marketing"
number.
I also removed the sentence about not
removing deprecated API if release train projects rely on it. The intent
was that we would work with the community and try to accommodate their
needs - maybe they have a very good reason why they can't switch off the
deprecated API and we want to be good citizens rather than unilaterally
breaking people. However I don't think such an inflexible rule needs to
be baked into our policy. We already have this paragraph which conveys
the same message:
"Objections raised to the announced removal will
be considered, and options such as delaying removal, abandoning removal,
or supplying compatibility support for affected clients will be considered
based on community feedback."
I didn't get into specifics about tooling-friendly
markup, such as the @until we have been discussing. We got bogged down
in the semantics of the tag arguments and don't want that to hold us back
from making progress. As you said we can add more detail in the policy
later if we do start using such tags.
My second attempt at the policy can
be found here:
http://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy
John
Hi John,
this looks very good! Things that
I noticed:
- In the section about major releases:
"For example if an API
is deprecated in release 3.9"
you may want to better pick "3.6" as example for clarity.
- I do not understand the section
"In addition, the Eclipse
Project will not delete deprecated API as part of an Eclipse Foundation
simultaneous release..." If
this is an additional constraint, it means that at the point where project
X has been "unable to cease using deprecated API" that API had
been announced for removal for 2 years already! Now if an Eclipse Foundation
Release Train project is unable to cease using API that's scheduled for
deletion, that is a bad sign of the state of that project, isn't it? Should
such a project be allowed to remain on the release train?
Having that statement in there seems to be unnecessarily weakening our
position on API deprecation and deletion. We should not make the rules
softer forrelease train projects, but we should be making them harder!
- The section about "Announcing
API Removal" does not specify any technique for how the "to be
deleted" status of API would be processable by automated tools. This
may not be necessary in the context of this policy though. I remember having
controversial discussions about how to do the markup, and the question
of markup should not be holding up the policy. But we may want to add markup
information in an addendum at a later point in time.
- A corollary of your policy is
that at any point X in time, the current snapshot of the porting guide
in CVS has the exact list of API to be removed from the Eclipse project
as well as the times when removal is scheduled to occur. It may be worth
explicitly noting this.
Thanks
for taking action on this policy!
Martin
From: eclipse-pmc-bounces@xxxxxxxxxxx
[mailto:eclipse-pmc-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: Friday, October 23, 2009 11:43 PM
To: eclipse-pmc@xxxxxxxxxxx
Subject: [eclipse-pmc] Draft deprecation policy
PMC members,
We've been discussing an Eclipse project deprecation policy on and off
for the past year or so. With some guidance from McQ, I have written up
a draft guideline for further discussion. Please look it over and we can
discuss it at the next PMC call (or feel free to edit/add comments directly
in the wiki page).
http://wiki.eclipse.org/Eclipse/API_Central/Deprecation_Policy
John_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
|
