Re: Tracking backward-incompatible changes for Beam

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 wrote: > I don't think we have it

Re: Tracking backward-incompatible changes for Beam

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 wrote: > +1 for the labels and also a need for tests. > Do we document any rules for

Re: Tracking backward-incompatible changes for Beam

+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 wrote: > It would be awesome to have that! At least a good portion of >

Re: Tracking backward-incompatible changes for Beam

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é wrote: > Hi Dan, > > +1, good idea. > > Regards > JB > > On 10/21/2016 02:21 AM, Dan Halperin wrote: > > Hey

Re: Tracking backward-incompatible changes for Beam

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

Tracking backward-incompatible changes for Beam

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