On Jun 28, 2015 2:01 AM, "Mikhail Antonov" <[email protected]> wrote: > > >>> The change of HTable from public/stable to private/stable is abrupt without a transition through deprecation. > > I actually missed this part, looked at branch-1.0 but no further > behind. Then we may want to keep it longer.. I'm fine either way. >
Let's just add a note not to break it in 1.y. That should be enough transition time. > >>> There is none. If Private, semvar does not apply; no deprecation cycle necessary. > Given that case with abrupt transition of HTable, wondering if we want > to restrict transitioning from public to private, so it's not used as > a loophole :) > We already only allow public -> private on major. We should be doing a @deprecation beforehand, but I think 1.0 was handled as a special case since it was "the start". As an aside, private -> public should only happen on minor, since it adds to the API. > >>> What to do about Public/Evolving. semvar applies here? > When we introduce new client facing features, do we first mark them > public/evolving, and then promote to public/stable after every detail > settles down and get polished? Thinking out loud, I'd say - > public/evolving would comply with semver, except maybe that adding new > backward-compatible functionality in patch release is ok too. This may > allow us to faster absorb users' feedback on experimental things? > Currently, the evolving tag says that we can break compat on minor release. Personally, I don't care for this exception. I'd prefer it just indicate how likely to add to or break an API we are. (Or maybe allow removal without deprecation on major) I'm opposed to any weakening of the restrictions on patch releases, because they should be as low risk as possible. -- Sean
