> So you would say in 2.2.3 we "break" that again? Not wait for 3.0 because, > even if it was perhaps an accident, support was there?
Yep. If others agree this is the way to go, I'd be happy to. We had some other changes that worked "accidentally" but were never stated that they work this way. I think it's a pretty good assumption (even if it is implicit) that "params" set for dag triggering are "data" and not "code". It could be python callable of course, but I think it's kinda "abuse" - especially that it excludes triggering via CLI/UI. The thing is that we do not "specify" what is our "stable API" and what is not also in many other places, there is a certain ambiguity for some of them. Of course it's not only whether it is "specified" or "not", it's also much more "whether a lot of people could interpret and use it in this way". I think (but maybe others can chime in) - it would be reasonable to assume that using callables or other Python Code is expected when we already have: a) CLI with string/JSON input b) UI with string/JSON input c) ability of using JSON-schema to actually verify the parameters (this last one actually shows a clear intention of having those parameters "data only").. J.
