In general I agree but in I don't think this is going to work as you expect because not all users are able to upgrade to the latest minor version easily. I can say for myself I'm on 2.2.3 and I can not upgrade - even not to 2.2.5 The reason is not related to Airflow at all but more to an internal policy (I can explain why but not sure it's relevant for this discussion)
I am concerned that limiting the list will result in false reports of versions which may cause confusion for us. That said, I think we can consider just removing all 2.0 and 2.1 series from the list. The reason I'm suggesting this is - everytime I see an issue on these versions I ask "is it reproducible on main/latest version?" and wait for the user to reply. So we can explain that in the case of 2.0 and 2.1 series bug reports we ask users to check the issue on the latest version and submit the bug report on that version. On Thu, Jul 21, 2022 at 12:35 PM Jarek Potiuk <ja...@potiuk.com> wrote: > (second line should be 2.3.2 -> for a few days after 2.3.3 is released > > On Thu, Jul 21, 2022 at 11:34 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > > > Hello everyone, > > > > I've looked at some issues raised recently and I have an idea on how > > to make diagnosis of problems raised by our users a bit more > > "efficient". It should also help to address "version" proliferation ve > > have in the issue template. > > > > The list grows longer and longer the more releases we make, however - > > more often than not whenever someone reports an issue on (say 2.2.1), > > and we "suspect" the problem might be solved already we suggest the > > users to upgrade first to at least latest in 2.2.* line and see if it > > works. > > > > As counterintuitive as it seems for an engineer, it might often be the > > faster solution - similarly like "bisecting" is a good way of finding > > a solution without knowing the root cause is, upgrading to the latest > > version in the line might often be the best idea to solve a problem. > > Maybe we do not know the root cause, but if the problem is solved. It > > means that the result is achieved (i.e. problem solved) and the > > problem has been investigated and solved (or maybe it was solved > > accidentally but it does not make it "less solved"). > > > > Now - maybe we should consider to build our list of versions this way > > (Compare it to the current long list we have there now). > > > > * 2.3.3 -> latest > > * 2.3.3 -> for a few days after 2.3.3 is released > > * 2.2.5 > > * 2.1.4 > > * 2.0.2 > > * main (development) > > > > > > And update the note above similar to: > > > > Only Airflow 2 is supported for bugs. If you do not see your version > > here please upgrade to the latest version in your Y.X line and check > > if your issue is solved there before reporting or open discussion > > instead. > > > > Upgrading to the latest bugfix version should generally always happen. > > If the user does not do it, they miss the latest bug-fixes in the line > > and risk really nothing. > > > > I think this might have some nice effects: > > > > * people might upgrade earlier > > * no time lost on diagnosing of already solved issues by both - > > reporting users and those who try to help > > * stronger communication of "we really support only latest versions > > from the line > > * potentially faster rollout and pressure on managed versions of > > Airflow to upgrade to the latest bugfix - as their users might start > > asking the questions to them rather than to us if they do not see the > > version on the list. > > > > WDYT? > > > > J. >
