On Sun, Jun 28, 2015 at 6:32 AM, Sean Busbey <[email protected]> wrote:
> 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. > > Ok. HBASE-13983 Thanks for the input, St.Ack > > >>> 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 >
