Hi Przemysław and Jarek, Thanks for taking the time to look at this thread.
On the comment threads first: the page was probably giving a misleading impression, I had left multiple threads open after replying to them, so that commenters could come back with a follow-up and other reviewers could find the discussion easily. But now I've resolved the ones that are already incorporated into the text. On the specifics of the mentioned comments, I'd like to explain where I've landed on the two open ones, because I don't think either is a gap in the document as it stands. 1. Ash's point about active_dag_version_id, was that the scheduler shouldn't have to decide which version to use. I don't think it does. The version is resolved by the query the scheduler already issues, in the same way it resolves the latest DagVersion today - there's no branch or decision on the scheduler's side, just a different resolution behind the same read. On the alternative of having the parser write the column instead: the column could then no longer tell us on its own whether a Dag is pinned, so we'd need an additional flag to distinguish "no pin" from "pinned", and we'd have two writers on the same active version column. The current design avoids both. I didn't think that was a strong enough concern or decision to be included into the main text, but let me know if you feel otherwise. 2. Christos' point on Divergence Detection: I'd rather the AIP align on which kinds of divergence need to be surfaced, and leave how they're detected to implementation. Detection here is a non-functional requirement, and pinning down a mechanism in the AIP would commit us to details that may be better settled with working code. I'm willing to work through the cases themselves if there's disagreement about which ones matter. Jarek, on the risk of rushing: the proposal has been in discussion since April and has been through several rounds of review here and on the cwiki page, including a first vote I paused in July to work through Ephraim's feedback before restarting. I've tried not to move it faster than the review could keep up. If there are particular ripple effects you're concerned about, I'd genuinely like to hear them - that feedback has improved this proposal at every round, and I'd rather keep iterating with concrete feedback than push for a quick close. On the release timeline, the AIP never proposed a target version, and I have no attachment to 3.4.0. 3.5.0 or later is completely fine by me, and I'll follow whatever suits the release plan. So I think the target version shouldn't be a factor for this vote. On the flip side though, there is a cost to deciding much later. The proposal describes a moving codebase - I originally wrote it against 3.2.0, and changes upstream since then have already made me materially revise or extend parts of it multiple times over the past few months. So while I don't mind which release it lands in, a long delay on the decision itself means re-verifying and reworking the document against a baseline that has moved again in the meantime. Lastly, I want to make sure I'm working towards the right bar. I haven't been able to concretely understand what specific changes would resolve the concerns raised. If you can point me at the particular points you'd want covered, I can work through them the same way I've handled the other review comments. Thanks again, Piyush On Sun, Sep 20, 2026 at 7:21 PM Jarek Potiuk <[email protected]> wrote: > -1 (binding). I agree with Przemek. This change has far too > many ripple-effects with this change to make a rushed decision on it. And > That one seems like a good candidate on 3.5.0 rather than 3.4.0 - we should > limit the feature scope for 3.4.0 IMHO to what is already pretty advanced. > > On Sun, Sep 20, 2026 at 1:30 PM Przemysław Mirowski <[email protected]> > wrote: > > > -1 (binding) at least for now. I would like Ash and Christos' > > comments/concerns to be resolved in the AIP document before proceeding > with > > voting. These comments are connected to the scheduler and pin guard, both > > important for this change. > > > > On 2026/09/14 11:36:45 Piyush Maheshwari wrote: > > > Hi everyone, > > > > > > I am extending the voting period on AIP-109 by another week to allow > more > > > time for review and voting. > > > The vote will now close on Monday, 21 Sept 2026, at 0700 GMT. > > > > > > Regards, > > > Piyush > > > > > > > > > On Wed, Sep 9, 2026 at 10:54 PM Sumit Maheshwari < > [email protected] > > > > > > wrote: > > > > > > > +1 (binding) > > > > > > > > On Mon, Sep 7, 2026 at 11:57 AM Piyush Maheshwari < > > > > [email protected]> wrote: > > > > > > > > > Hi everyone, > > > > > > > > > > I would like to restart a vote on AIP-109 DAG Version Pinning: > > > > > > > https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-109+DAG+Version > > > > > +Pinning > > > > > > > > > > The discussion thread can be found here: > > > > > https://lists.apache.org/thread/6h811nmzjrgfhj1b0kwqtjjlhvc5jrvr > > > > > > > > > > Thanks to everyone who reviewed the AIP and participated in the > > > > > discussions. I've addressed all comments. > > > > > > > > > > The vote will remain open for 5 working days and will close on > > *Monday, > > > > 14 > > > > > Sept 2026, at 0700 GMT*. > > > > > > > > > > Everyone is encouraged to vote, although only votes from PMC > members > > and > > > > > committers are considered binding. > > > > > > > > > > Please vote accordingly: > > > > > > > > > > [ ] +1 Approve > > > > > [ ] +0 no opinion > > > > > [ ] -1 disapprove with the reason > > > > > > > > > > Regards, > > > > > Piyush > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
