Topic on Talk:Stable interface policy/Archive 2

The deprecation procedure has been made part of the stable interface policy draft.

What's the advantage of having a separate policy for this? Why not integrate the new stuff into the existing deprecation policy?

Because it's long, and defining what's stable is different from defining how to change stable things. The primary audience for the deprecation policy are core developers, while the primary audience for the stable interface policy are extension developers.

I'm not totally opposed to having a single policy, but I think it's less clear. And RFC is needed for adoption in any case.

If we only have one policy, I think it should be called "Stable Interface Policy", and the deprecation process would be part of that.

Because, as a new extension developer, "stable interface policy" sounds like something I should look at (I want to use stable interfaces), but "deprecation policy" doesn't sound so interesting (I don't want to deprecate anything).

I agree we should not be enacting a new policy. It is a new RFC for sure, but its outcome should be to revise the deprecation policy including possibly a rename of it.

The main part I currently find difficult in reviewing this draft is that it is unclear what is meant to be "new" or "different" from what we have. Perhaps we can update the draft to be a complete version of the policy, with the task outlining a (short) summary what what we intend to add or change (e.g. the effective difference).

So, which do you prefer - an deprecation policy with a section on stable interfaces, or a stable interface policy with a section on deprecation procedures?