If the API/semantics are sufficiently well tested, backwards incompatibility should manifest as test failures. The corollary is that one should look closely at any test changes that get proposed.
On Mon, Oct 24, 2016 at 1:52 PM, Davor Bonaci <[email protected]> wrote: > I don't think we have it right now. We should, of course, but this is > something that needs to be defined/discussed first. > > On Mon, Oct 24, 2016 at 1:20 PM, Neelesh Salian <[email protected]> > wrote: > >> +1 for the labels and also a need for tests. >> Do we document any rules for backward-compatibility? Be good to have a >> checklist-like list. >> >> >> >> >> On Mon, Oct 24, 2016 at 1:02 PM, Davor Bonaci <[email protected]> >> wrote: >> >> > It would be awesome to have that! At least a good portion of >> > backward-incompatible changes could be automatically caught. >> > >> > We should also think about defining backward-compatibility more >> precisely. >> > This would be good in its own right, but also necessary to configure the >> > tool. Historically, we have applied the backward-compatibility rules on >> > APIs that are intended for users, excluding experimental ones, but not >> > necessarily on all publicly visible APIs. If we continue this practice, >> it >> > might be a challenge for the tool. In any case, I think there's a good >> > discussion to be had around what backward-compatibility means exactly in >> > Beam. >> > >> > On Sat, Oct 22, 2016 at 2:47 AM, Aljoscha Krettek <[email protected]> >> > wrote: >> > >> > > Very good idea! >> > > >> > > Should we already start thinking about automatic tests for backwards >> > > compatibility of the API? >> > > >> > > On Fri, 21 Oct 2016 at 10:56 Jean-Baptiste Onofré <[email protected]> >> > wrote: >> > > >> > > > Hi Dan, >> > > > >> > > > +1, good idea. >> > > > >> > > > Regards >> > > > JB >> > > > >> > > > On 10/21/2016 02:21 AM, Dan Halperin wrote: >> > > > > Hey everyone, >> > > > > >> > > > > In the Beam codebase, we’ve improved, rewritten, or deleted many >> > APIs. >> > > > > While this has improved the model and gives us great freedom to >> > > > experiment, >> > > > > we are also causing churn on users authoring Beam libraries and >> > > > pipelines. >> > > > > >> > > > > To really kick off Beam as something users can depend on, we need >> to >> > > > > stabilize the Beam API. Stabilizing means a commitment to not >> making >> > > > > breaking changes -- except between major versions as per standard >> > > > semantic >> > > > > versioning. >> > > > > >> > > > > To get there, I’ve started a process for tracking these changes by >> > > > applying >> > > > > the `backward-incompatible` label [1] to the corresponding JIRA >> > issues. >> > > > > Naturally, open `backward-incompatible` changes are “blocking >> issues” >> > > for >> > > > > the first stable release. (Or we’ll have to put them off for the >> next >> > > > major >> > > > > version!) >> > > > > >> > > > > So here are some requests for help: >> > > > > * Please review and appropriately label the components I skipped: >> > > > > runner-{apex, flink, gearpump, spark}, sdk-py. >> > > > > * Please proactively file JIRA issues for breaking API changes you >> > > still >> > > > > want to make, and label them. >> > > > > >> > > > > Thanks everyone! >> > > > > Dan >> > > > > >> > > > > >> > > > > [1] >> > > > > >> > > > https://issues.apache.org/jira/issues/?jql=project%20% >> > > 3D%20BEAM%20AND%20labels%20%3D%20backward-incompatible >> > > > > >> > > > >> > > > -- >> > > > Jean-Baptiste Onofré >> > > > [email protected] >> > > > http://blog.nanthrax.net >> > > > Talend - http://www.talend.com >> > > > >> > > >> > >> >> >> >> -- >> Neelesh Srinivas Salian >> Customer Operations Engineer >>
