This is a very good point. I'd love to hear what others think about it. I have my thoughts there but will keep my mouth shut for a while this time to hear from others first :)
On Wed, May 4, 2022 at 6:32 PM Robin Edwards <[email protected]> wrote: > This is probably slightly touching on the issues Jarek and Kevin were > discussing in the release announcement however i think it warrants its > own thread. > > Firstly i'd like to thank everyone for their hard work in 2.3, I > haven't had time to try it out yet but i do look forward giving it a > spin. > > We run a fairly large Airflow installation that has been running from > early in the 1. series. > > One thing i've observed since the start of the 2 series is that the > minor releases 2.1, 2.2, 2.3 contain quite ambitious feature changes. > These series often don't mature until 2 or so patch releases. I am not > pointing fingers here it's just the nature of shipping software. > > When a new minor release comes out any outstanding fixes for the > previous series (2.2) now get moved and applied to the new series > (2.3). This can be quite problematic for a user, either bite the > bullet and do a risky upgrade to a .0 release or run our own build > with the given patches applied. The obvious issue with the latter is > your potentially running different code paths to everyone else which > makes getting support hard. > > As far as i am aware the larger vendors maintain their own builds with > extra patches applied. For smaller teams (or new users) doing this is > prohibitive. I guess this is one of the selling points of paying for a > managed service. > > Would it be possible to continue support for the previous minor series > with patch releases whilst the new minor release matures? I know such > a thing isn't uncommon in other projects such as Postgres (all be it > with major releases). > > Obviously I am aware a lot of time and effort goes into cutting a > release, for which I am eternally greatful :-) > > R >
