...

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users?
• If we are changing behavior how will we phase out the older behavior?
• If we need special migration tools, describe them here.
• When will we remove the existing behavior?

Test Plan

We shall deprecate the following methods

Processor.punctuate(long timestamp), Transformer.punctuate(long timestamp), ProcessorContext.schedule(long interval);

The deprecated methods shall remain for some time along the newly added ones to allow a smooth migration.

The semantics of the deprecated methods shall remain unchanged.

A call to the deprecated ProcessorContext.schedule(interval) from within a Processor will be equivalent to:

context.schedule(PunctuationType.STREAM_TIME, this::punctuate);

A call to the deprecated ProcessorContext.schedule(interval) from within a Transformer will be equivalent to:

context.schedule(PunctuationType.STREAM_TIME, timestamp -> {
	KeyValue<K,V> pair = punctuate(timestamp);
	if (record != null) {
		context.forward(pair.key, pair.value);
	}
});

Test Plan

Stream time, system time and a mix of both PunctuationTypes should be tested. Existing test for punctuation can be re-used to guide the test cases for stream time only. System time and mixed stream & system time tests will have to be developed.Describe in few sentences how the KIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.