Hello, Very good topic to discuss! I would like to clarify something before diving in the topic, when you say βthe provider's releases are very frequent (almost monthly)β, are you talking about major releases only or any releases? Do we actually make a difference?
Other than that, my thoughts on the 3 months period before removing any deprecated code is a bit short in my opinion. It means, in a 3 months period, a developer needs to: 1. Find out the deprecation by catching warning message while working on it 2. Investigate the alternative solution 3. Implement the alternative 4. Test 5. Deploy To me it is a bit aggressive and too demanding for the developers. I would extend the period to 6 months. My 2 cents π Vincent From: Elad Kalif <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Friday, May 20, 2022 at 10:37 AM To: "[email protected]" <[email protected]> Subject: [EXTERNAL] [DISCUSS] - Policy for removing deprecated code from providers CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi everyone, Unlike Airflow core, the provider's releases are very frequent (almost monthly). This means that in theory we can introduce deprecation in April and remove the feature in May. To my knowledge the first time we actually removed deprecated features was in the last Google Provider release (7.0.0) and to my understanding it caught some users by surprise so I'd like to set policy for this and document it in the project readme file. My suggestion: Deprecation will stay for at least 3 months from release date, e.g depreciation introduced on 1st April can be removed at any major release after 1st July but not sooner except in the rare cases where we have good reason to remove sooner. What are your thoughts here?
