Hey Shrividya, Agree with Rahul here. We deliberately introduced friction - and make it a bit "harder" to report issues for older versions - we even specifically "hint" people to check it on the latest version:
> On what 3.X version of Airflow are you currently experiencing the issue? Remember, you are encouraged to > test with the latest release or on the `main` branch to verify your issue still exists, especially if > your version is at least a minor version older than the [current stable release]( https://airflow.apache.org/docs/apache-airflow/stable/installation/supported-versions.html#version-life-cycle ). And yes - your goal when designing such an interaction might not be "to make it easier for the user." In this case our optimisation goal is to make things deliberately harder, when you want user to at least be aware that there is potentially another path they could make - upgrade or check the issue. That design was deliberately built into the template form and I think it should stay. You might of course propose another solution for it - but make sure to target the goal J. On Sun, Mar 22, 2026 at 9:32 AM Rahul Vats <[email protected]> wrote: > Thanks Shrividya! > > On version awareness, most users are data engineers and in my experience, > triaging issues, they generally know the version against which bug is being > raised. I have not really come across cases where someone picked the wrong > version because they were unsure. > On the "Other Airflow 3 version" option, I think the intent was to keep the > dropdown from growing too long as new patch versions are released, rather > than a sign that the dropdown is not solving the problem. A curated list > actually makes it easier for reporters to pick the right value quickly. > > I think the other changes in this PR are solid. Merging "What happened" and > "How to reproduce" makes a lot of sense, and making OS and deployment > optional is a good call. My concern is specifically around the free form > text field, but happy to listen to other opinions as well > > Thanks, > Rahul > > On Sun, 22 Mar 2026 at 12:10, Shrividya Hegde <[email protected] > > > wrote: > > > 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 > > > > > >
