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 >
