Re: draft lithium release plan

Ed Warnicke (eaw) <eaw@...>

On Oct 24, 2014, at 1:49 PM, Chris Wright <chrisw@...> wrote:

* Colin Dixon (colin@...) wrote:
The draft release plan that Phil and I have been working on is ready for
comments. You can find it here:
I think a Legacy API sounds like something old where there is also a
newer way to do the same thing. I'd suggest Stable API.
I was thinking something similar, and concur. To my ear, a legacy API is something we
expect to be deprecating sooner or later (other ears may disagree ;) ). So I second renaming
Legacy API to Stable API in the plan.

I would also suggest that we need to figure out what the exception process looks like, because there is
*always* an exception to every rule.

Further, I would strongly suggest that we adopt a calling out of Legacy(Stable APIs) rather than a
calling out of Provisional/Tentative APIs. Unless we are going to essentially force API freeze at M1,
I as a developer have *no* way of knowing what APIs will prove needful as we do development,
so defaulting to Legacy(Stable) makes no sense to me. It is important to keep in mind that a projects
Release Plan is a statement of what it thinks it will do, not a restriction on what it *can* do. To treat it otherwise
is to choke innovation.

I don't understand this part of Provisional API:

"...or an externally accessible API that existed in a previous version
of ODL but is being modified for the current release."

The part that is unclear to me is the state the API was in during the
previous version. IOW, to me it _had_ to be Provisional to begin with,
else you couldn't change it. If it was Legacy (Stable?) to begin with,
then this is a _new_ API, and certainly the new API is Provisional.

Also, I think the APIs should be marked in code, annotations being one
obvious way to do it (in today's call we touched on deprecated, and only
exporting supported APIs)? The ability to enumerate externally consumable
APIs should be automated, and even better, the API state marked in the
code so that it's clear to the consumer what contract you are receiving.
I strongly concur about marking in codeā€¦ anyone willing to do a quick annotation?


TSC mailing list

Join to automatically receive all group messages.