potiuk commented on PR #30727: URL: https://github.com/apache/airflow/pull/30727#issuecomment-1622289490
> I respectfully disagree. IMO, internal enhancements should be welcomed in patch versions as well. Nice discussion :). I think I agree with both statements. I think the key is "Potential to cause problems". There is a class of improvements that should be welcome. Automated refactorings, build improvements, some speed optimizations that are easily verifiable and reviewable. Yes. But at the moment when you have one person scratching their head telling "You know, I am not sure if we thought of all consequences, I think this optimisation is a bit risky" - that's a clear sign of non-patchlevel release IMHO. This is really the matter of trust and communication we build with our users. If we want to convince our users to follow the SemVer approach - they do not expect there will be regressions in patchlevel, so we should make sure, to avoid them, and certainly there should be no regressions that are coming from somethig that is not a "fix" to an issue. And yes, it's blurry and mor quantum stuff where we are talking about probability of something happening not 0/1 decisions. Generally speaking if a change is very unlikely to cause a problem, it's fine to consider it. > However, it is worth noting that until version 2.5.3, the executors were considered part of the public API. In version 2.6.0, we clarified that only the executor interface is public, while instances are not (https://github.com/apache/airflow/pull/29200). For that, I think we should merge this PR when we cut 2.7.0 to avoid introducing a breaking change for some users. Not sure if I understand? do you expect it to wait until AFTER we cut 2.7.0? I am not sure we need it. The clarification is not really tied to specific version. It was merely documenting what we did not have documented reallly but we implicitly knew it. We already "broke" a number of those in the past - for example DB structure changes which we never before explicitly stated as "internal detail" before. I think we never really said "you can extend Kubernetes Executor and it will remain as it is", we said "you can write your own executor" - those are different things. I think in case of the "Public Interface" docs we just clarified the intentions we had when it comes about compatibillty, but we never changed the intentions, they were just poorly (or rather not) documented. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
