On 13/06/2023 17:26, Becket Qin wrote:
It would be valuable if we can avoid releasing minor versions for previous
major versions.
On paper, /absolutely /agree, but I'm not sure how viable that is in
practice.
On the current 2.0 agenda is potentially dropping support for Java 8/11,
which may very well be a problem for our current users.
On 13/06/2023 17:26, Becket Qin wrote:
Thanks for the feedback and sorry for the confusion about Public API
deprecation. I just noticed that there was a mistake in the NOTES part for
Public API due to a copy-paste error... I just fixed it.
I'm very relieved to hear that. Glad to hear that we are on the same
page on that note.
On 15/06/2023 15:20, Becket Qin wrote:
But it should be
completely OK to bump up the major version if we really want to get rid of
a public API, right?
Technically yes, but look at how long it took to get us to 2.0. ;)
There's a separate discussion to be had on the cadence of major releases
going forward, and there seem to be different opinions on that.
If we take the Kafka example of 2 minor releases between major ones,
that for us means that users have to potentially deal with breaking
changes every 6 months, which seems like a lot.
Given our track record I would prefer a regular cycle (1-2 years) to
force us to think about this whole topic, and not put it again to the
wayside and giving us (and users) a clear expectation on when breaking
changes can be made.
But again, maybe this should be in a separate thread.
On 14/06/2023 11:37, Becket Qin wrote:
Do you have an example of behavioral change in mind? Not sure I fully
understand the concern for behavioral change here.
This could be a lot of things. It can be performance in certain
edge-cases, a bug fix that users (maybe unknowingly) relied upon
(https://xkcd.com/1172/), a semantic change to some API.
For a concrete example, consider the job submission. A few releases back
we made changes such that the initialization of the job master happens
asynchronously.
This meant the job submission call returns sooner, and the job state
enum was extended to cover this state.
API-wise we consider this a compatible change, but the observed behavior
may be different.
Metrics are another example; I believe over time we changed what some
metrics returned a few times.
