hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Semantic Versioning Worksheet
Date Sun, 28 Jun 2015 18:13:14 GMT
Wrt evolving, I would like it to mean, at least, that we can add new
methods to patch releases. Add only.


On Sunday, June 28, 2015, Sean Busbey <busbey@cloudera.com> wrote:

> On Jun 28, 2015 2:01 AM, "Mikhail Antonov" <olorinbant@gmail.com
> <javascript:;>> 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
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message