> Now, one elephant in the room - the 5 year security patches thing Jarek brought up. I freely admit I haven't tracked this at all, so please correct me if I'm wrong. If that ends up panning out though, I think we will have to reassess our strategy with providers too.
Just to answer the last point. Yes. I believe so. I was never a big fan of introducing breaking changes in providers to make maintainers' lives a bit easier. While I was a big fan of doing it when we had a very good reason. I think we have too many breaking changes in providers now. And we do it because we "can" - we mostly only consider maintainer's lives easier currently. But I think when those regulations are in place we will have to make a much more deliberate judgment on when we make a major release in providers and take on a deliberate decision "is it worth doing it, knowing that we will have to deliver patches for previous major versions". This will be something that the regulations might make us think about when making a decision "should we break?". And when we do - we should be prepared to cherry-pick security fixes to those old versions. We currently can have a process for it - and it is off-loaded mainly to stakeholders. https://github.com/apache/airflow/blob/main/PROVIDERS.rst#mixed-governance-model - where we mainly take care about releasing cherry-picked code. I believe the overwhelming majority of those "breaking" releases that we really needed, were in providers where there is an active stakeholder already cooperating with us. I have - honestly quite an expectation that this will stay like that. In the proposed regulations, the stakeholders are (much more than the OSS foundations) responsible for security of the software they provide to their users and they will have incentive to fix and provide fixes also for past releases of those integration. And I think we can work out a collaborative model on that - very close to the "mixed governance" we already have. And in other cases where we have no active stakeholders, we might simply refrain from making breaking changes if not absolutely needed. That would be my approach to the elephant. J,
