Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 saint.ack@gmail.com does not designate 54.164.171.186 as permitted sender)
MIME-Version: 1.0
Sender: saint.ack@gmail.com
In-Reply-To: 
 <CAGHyZ6LtU+CJP9fAtq+wSq-kFsXyPvFG2qPLPoHiOP+QhWSUWQ@mail.gmail.com>
References: 
 <CA+RK=_CkTUfa3nWPsy2A0PZt07h=1stP72rcazBrw5U0JFdgXA@mail.gmail.com>
	<5537D45D.3020207@gmail.com>
	<CAGHyZ6L3kMQgACjujFyGBOiKbHNXW=-hc=7+G-cE-+y5BDSakg@mail.gmail.com>
	<5537DBF5.6080204@gmail.com>
	<CA+RK=_AnCe-XwGjguw1=SyZObBe2EVLO=969C_Qy1ChEdiZfWQ@mail.gmail.com>
	<CAMUu0w_4YM-oM0u4KQ0AOdrxGf=qkGxdk5Z2PZ9=WS5Nw0xLvQ@mail.gmail.com>
	<CAGHyZ6LtU+CJP9fAtq+wSq-kFsXyPvFG2qPLPoHiOP+QhWSUWQ@mail.gmail.com>
Date: Thu, 23 Apr 2015 13:48:05 -0700
Message-ID: 
 <CADcMMgGmfwSxDPMs3rR-JMzvn4bSyXZCyc+OHG_eb4s9aqFsOg@mail.gmail.com>
Subject: Re: Clarifying interface evolution freedom in patch releases (was:
 Re: [VOTE] Third release candidate for HBase 1.0.1 (RC2))
From: Stack <stack@duboce.net>
To: HBase Dev List <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=001a1147d518813a5505146a653b

--001a1147d518813a5505146a653b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I agree w/ the Enis characterization (so we need the callout on semvar) but
think we should practice what Seans says (patch is bug fixes only).
St.Ack

On Thu, Apr 23, 2015 at 1:31 PM, Sean Busbey <busbey@cloudera.com> wrote:

> Why don't we just focus development after a minor release on the next min=
or
> release instead of the next patch release?
>
> We could limit backports to the patch releases to critical bugs, which
> would cut down on how often someone has to deal with the pain of making
> sure we don't add to public APIs. It also reduces the risk someone going
> through an upgrade has, since there are fewer changes.
>
> If someone fixes a bug and doesn't want to do the work of making sure it
> doesn't add methods in a patch release, they just don't backport to that
> version and make a follow on e.g. "backport to 1.0.z" ticket.
>
>
>
> On Thu, Apr 23, 2015 at 1:50 PM, Enis S=C3=B6ztutar <enis.soz@gmail.com> =
wrote:
>
> > +1 to the proposal.
> >
> > The problem is that we have a very big API surface especially with the
> > coprocessors included in the report. Even simple bug fixes can introduc=
e
> > protected or public methods to base classes, which makes patch releases
> > very hard to maintain. I would not want to spend the effort to spend to=
ns
> > of time trying to make a patch not introduce new methods in order to
> > backport. That effort can be spent elsewhere IMO.
> >
> > Looking at the report
> > https://people.apache.org/~enis/1.0.0_1.0.1RC2_compat_report.html,
> nothing
> > strikes me as "new functionality". Going from current 1.0.0 to 1.0.1RC2
> > should actually be as you would expect from upgrading a patch release.
> >
> > Yes, adding new API in patch releases will make downgrading harder, but=
 I
> > think that is an acceptable tradeoff. We can document that if your
> > application compiles (meaning that you are not using new API) with 1.0.=
0,
> > then you can swap your jars in a binary compat manner.
> >
> > Enis
> >
> > On Thu, Apr 23, 2015 at 10:03 AM, Andrew Purtell <apurtell@apache.org>
> > wrote:
> >
> > > Anyone disagree with the point of view put forward by Josh and Sean?
> > >
> > >
> > > On Wed, Apr 22, 2015 at 10:35 AM, Josh Elser <josh.elser@gmail.com>
> > wrote:
> > >
> > > > Andy -- I understood your intent, but thanks for clarifying. (as we=
ll
> > as
> > > > taking the time to break this discussion out in the first place). I
> > agree
> > > > with your assessment.
> > > >
> > > > re: Sean's comments, if it wasn't clear by me asking in the first
> > place,
> > > I
> > > > also think sticking as close as possible to semver's rules is the
> best
> > > > approach, although I'm getting the impression that there have been
> some
> > > > previous reservations to doing so (especially by your comment about
> > > > backporting features if there is demand is).
> > > >
> > > > I've found adhering to the bug-fix release restrictions can be a ve=
ry
> > > > painful and time-consuming task, so this is something to get a
> > > > representative sampling of those who do the work to make sure
> everyone
> > is
> > > > on board.
> > > >
> > > >
> > > > Sean Busbey wrote:
> > > >
> > > >> I'd much rather we stick with the definitions used in Semantic
> > > Versioning.
> > > >> Our use is already confusing enough given our matrix of
> > compatibilities
> > > >> that don't get "major version for breaking" protections.
> > > >>
> > > >> We've previously discussed how we'll do additional minor releases
> when
> > > >> there's sufficient interest in the new features present there.
> What's
> > > >> building that demand if any backwards compatible change can go bac=
k
> > > into a
> > > >> patch release?
> > > >>
> > > >> Would we have an easier time restraining ourselves if we had a
> regular
> > > >> schedule planned around new minor versions?
> > > >>
> > > >>
> > > >> On Wed, Apr 22, 2015 at 12:03 PM, Josh Elser<josh.elser@gmail.com>
> > > >> wrote:
> > > >>
> > > >>  While I can understand the desire to want to add things, I do thi=
nk
> > it
> > > >>> makes things harder for users to reliably write code against
> versions
> > > of
> > > >>> HBase which (by their view) should be completely compatible with
> one
> > > >>> another.
> > > >>>
> > > >>> Take this extremely hypothetical situation: I'm new to HBase and
> > start
> > > >>> writing some code against HBase 1.0.1 which was just deployed at =
my
> > > >>> $job. I
> > > >>> don't _know_ what APIs are new, I just know what exists and treat
> > that
> > > as
> > > >>> acceptable for me to be using. Meanwhile in production, some othe=
r
> > > people
> > > >>> find a bug with HBase 1.0.1 and roll back to 1.0.0 which they had
> > been
> > > >>> previously using. My reaction would be "of course my code should
> work
> > > >>> with
> > > >>> HBase 1.0.0, I only used the public API" when in fact this is not
> > true.
> > > >>>
> > > >>> Personally, I think it's a little bold to say semver is even in u=
se
> > if
> > > >>> this principal isn't being followed as it doesn't follow at all
> with
> > my
> > > >>> understanding on the guarantees defined by semver for bug-fix
> > releases.
> > > >>>
> > > >>> That being said, if the intent *is* to allow ourselves to make
> these
> > > >>> sorts
> > > >>> of changes, I just think some sort of disclaimer should be presen=
t:
> > > >>>
> > > >>> - HBase uses Semantic Versioning for its release versioning
> > > >>> + HBase uses Semantic Versioning for its release versioning with =
a
> > > caveat
> > > >>> that methods and members might be added in newer bug-fix releases
> > that
> > > >>> were
> > > >>> not present in the previous bug-fix release.
> > > >>>
> > > >>>
> > > >>> Andrew Purtell wrote:
> > > >>>
> > > >>>  [Subject changed]
> > > >>>>
> > > >>>> On Tue, Apr 21, 2015 at 8:47 PM, Josh Elser<josh.elser@gmail.com=
>
> > > >>>>  wrote:
> > > >>>>
> > > >>>>   I was a little surprised when I noticed method additions to
> > > >>>>
> > > >>>>> InterfaceAudience.Public annotated classes. This means that a
> user
> > > >>>>> could
> > > >>>>> write code against 1.0.1 that would not work against 1.0.0 whic=
h
> > > seems
> > > >>>>> undesirable for a bugfix release. I read over the book section =
on
> > > >>>>> compatibility and didn't see this addressed, so I thought I'd
> ask.
> > > >>>>>
> > > >>>>>
> > > >>>> Let's clarify this. It's not the first time this question has be=
en
> > > >>>> asked.
> > > >>>>
> > > >>>> To get things moving:
> > > >>>>
> > > >>>> I propose the following addition to the "Client API compatibilit=
y"
> > > >>>> section
> > > >>>> of Section 11.1:
> > > >>>>
> > > >>>> + APIs available in a patch version will be available in all lat=
er
> > > >>>> + patch versions. However, new APIs may be added which will not =
be
> > > >>>> + available in earlier patch versions.
> > > >>>>
> > > >>>> I propose the following change to the "Client Binary
> compatibility"
> > > >>>> section
> > > >>>> of Section 11.1:
> > > >>>>
> > > >>>> - Old client code can run unchanged (no recompilation needed)
> > against
> > > >>>> new
> > > >>>> jars.
> > > >>>> + Client code written to APIs available in a given patch release
> > > >>>> + can run unchanged (no recompilation needed) against the new
> > > >>>> + jars of later patch versions.
> > > >>>>
> > > >>>>
> > > >>>> What do you think?
> > > >>>>
> > > >>>> If these changes are (mostly) ok, then this clarifies in one
> > > direction.
> > > >>>>
> > > >>>> If these changes are not acceptable, I will propose edits that
> > clarify
> > > >>>> toward the opposite meaning. =E2=80=8B
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>
> > > >>
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >    - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> >
>
>
>
> --
> Sean
>

--001a1147d518813a5505146a653b--