Thanks for the response, Rahul! I get the reasoning behind the two-field setup, but I think the version confusion problem exists with a dropdown too. A reporter who doesn't know their exact version might just pick "3.x latest" even if they're on an older release. The issue is that they don't know their version, not how they're entering it.
Also, having "Other Airflow 3 version" as an option in the dropdown is a bit of a hint that the dropdown isn't really solving the problem on its own. A simple text field with a placeholder like `e.g. 3.1.8` does the same job with one less field, which is kind of the whole point of this PR. That said, if the group prefers keeping some structure, the conditional field idea you mentioned is a good middle ground. +1 on unifying the core and providers templates too! On Sun, 22 Mar, 2026, 2:24 am Rahul Vats, <[email protected]> wrote: > Thanks for raising this, Shrividya. I am totally in favor of simplifying > templates. > > One thing I wanted to clarify on the current two-field setup: the dropdown > covers the common versions (2.x, 3.x latest, main), and the secondary text > field is there for users who pick "Other Airflow 3 version" so they are not > really redundant, they serve different purposes. > > My hesitation with a fully free-text field is the version format. 3.1.8, > v3.1.8, airflow 3.1.8, 3.1 are all valid ways someone might type the same > version. The placeholder added in the PR helps, but it does not enforce a > format. One thing worth exploring: can the "If Other Airflow 3 version > selected, which one?" field be shown conditionally only when "Other Airflow > 3 version" is selected in the dropdown? That would reduce the visual noise > without losing the structure we have today. > > Also +1 to Shahar's idea of unifying the core and providers bug report > templates. That feels like the bigger simplification win in reducing the > current template count. > > Thanks, > Rahul >
