Change security.rst to use includes in providers

dev/provider_packages/prepare_provider_packages.py

@@ -1342,13 +1342,6 @@ def update_release_notes(
         regenerate_missing_docs,
     ):
         errors = True
-    if not update_security_rst(
-        jinja_context,
-        provider_package_id,
-        provider_details.documentation_provider_package_path,
-        regenerate_missing_docs,
-    ):
-        errors = True
     if not force:
         if not update_commits_rst(
             jinja_context,
@@ -1551,23 +1544,6 @@ def update_changelog_rst(
     )
 
 
-def update_security_rst(
-    context: dict[str, Any],
-    provider_package_id: str,
-    target_path: Path,
-    regenerate_missing_docs: bool,
-) -> bool:
-    return _update_file(
-        context=context,
-        template_name="PROVIDER_SECURITY",
-        extension=".rst",
-        file_name="security.rst",
-        provider_package_id=provider_package_id,
-        target_path=target_path,
-        regenerate_missing_docs=regenerate_missing_docs,
-    )
-
-
 def update_commits_rst(
     context: dict[str, Any],
     provider_package_id: str,

docs/apache-airflow-providers-airbyte/security.rst

@@ -1,4 +1,3 @@
-
  .. Licensed to the Apache Software Foundation (ASF) under one
     or more contributor license agreements.  See the NOTICE file
     distributed with this work for additional information
@@ -16,23 +15,4 @@
     specific language governing permissions and limitations
     under the License.
 
-Releasing security patches
---------------------------
-
-Airflow providers are released independently from Airflow itself and the information about vulnerabilities
-is published separately. You can upgrade providers independently from Airflow itself, following the
-instructions found in :doc:`apache-airflow:installation/installing-from-pypi`.
-
-When we release Provider version, the development is always done from the ``main`` branch where we prepare
-the next version. The provider uses strict `SemVer <https://semver.org>`_ versioning policy. Depending on
-the scope of the change, Provider will get ''MAJOR'' version upgrade when there are
-breaking changes, ``MINOR`` version upgrade when there are new features or ``PATCHLEVEL`` version upgrade
-when there are only bug fixes (including security bugfixes) - and this is the only version that receives
-security fixes by default, so you should upgrade to latest version of the provider if you want to receive
-all released security fixes.
-
-The only exception to that rule is when we have a critical security fix and good reason to provide an
-out-of-band release for the provider, in which case stakeholders in the provider might decide to cherry-pick
-and prepare a branch for an older version of the provider following the
-`mixed governance model <https://github.com/apache/airflow/blob/main/PROVIDERS.rst#mixed-governance-model>`_
-and requires interested parties to cherry-pick and test the fixes.
+.. include:: ../exts/includes/security.rst

docs/apache-airflow-providers-alibaba/security.rst

@@ -1,4 +1,3 @@
-
  .. Licensed to the Apache Software Foundation (ASF) under one
     or more contributor license agreements.  See the NOTICE file
     distributed with this work for additional information
@@ -16,23 +15,4 @@
     specific language governing permissions and limitations
     under the License.
 
-Releasing security patches
---------------------------
-
-Airflow providers are released independently from Airflow itself and the information about vulnerabilities
-is published separately. You can upgrade providers independently from Airflow itself, following the
-instructions found in :doc:`apache-airflow:installation/installing-from-pypi`.
-
-When we release Provider version, the development is always done from the ``main`` branch where we prepare
-the next version. The provider uses strict `SemVer <https://semver.org>`_ versioning policy. Depending on
-the scope of the change, Provider will get ''MAJOR'' version upgrade when there are
-breaking changes, ``MINOR`` version upgrade when there are new features or ``PATCHLEVEL`` version upgrade
-when there are only bug fixes (including security bugfixes) - and this is the only version that receives
-security fixes by default, so you should upgrade to latest version of the provider if you want to receive
-all released security fixes.
-
-The only exception to that rule is when we have a critical security fix and good reason to provide an
-out-of-band release for the provider, in which case stakeholders in the provider might decide to cherry-pick
-and prepare a branch for an older version of the provider following the
-`mixed governance model <https://github.com/apache/airflow/blob/main/PROVIDERS.rst#mixed-governance-model>`_
-and requires interested parties to cherry-pick and test the fixes.
+.. include:: ../exts/includes/security.rst

docs/apache-airflow-providers-amazon/security.rst

@@ -1,4 +1,3 @@
-
  .. Licensed to the Apache Software Foundation (ASF) under one
     or more contributor license agreements.  See the NOTICE file
     distributed with this work for additional information
@@ -16,23 +15,4 @@
     specific language governing permissions and limitations
     under the License.
 
-Releasing security patches
---------------------------
-
-Airflow providers are released independently from Airflow itself and the information about vulnerabilities
-is published separately. You can upgrade providers independently from Airflow itself, following the
-instructions found in :doc:`apache-airflow:installation/installing-from-pypi`.
-
-When we release Provider version, the development is always done from the ``main`` branch where we prepare
-the next version. The provider uses strict `SemVer <https://semver.org>`_ versioning policy. Depending on
-the scope of the change, Provider will get ''MAJOR'' version upgrade when there are
-breaking changes, ``MINOR`` version upgrade when there are new features or ``PATCHLEVEL`` version upgrade
-when there are only bug fixes (including security bugfixes) - and this is the only version that receives
-security fixes by default, so you should upgrade to latest version of the provider if you want to receive
-all released security fixes.
-
-The only exception to that rule is when we have a critical security fix and good reason to provide an
-out-of-band release for the provider, in which case stakeholders in the provider might decide to cherry-pick
-and prepare a branch for an older version of the provider following the
-`mixed governance model <https://github.com/apache/airflow/blob/main/PROVIDERS.rst#mixed-governance-model>`_
-and requires interested parties to cherry-pick and test the fixes.
+.. include:: ../exts/includes/security.rst

docs/apache-airflow-providers-apache-beam/security.rst

@@ -1,4 +1,3 @@
-
  .. Licensed to the Apache Software Foundation (ASF) under one
     or more contributor license agreements.  See the NOTICE file
     distributed with this work for additional information
@@ -16,23 +15,4 @@
     specific language governing permissions and limitations
     under the License.
 
-Releasing security patches
---------------------------
-
-Airflow providers are released independently from Airflow itself and the information about vulnerabilities
-is published separately. You can upgrade providers independently from Airflow itself, following the
-instructions found in :doc:`apache-airflow:installation/installing-from-pypi`.
-
-When we release Provider version, the development is always done from the ``main`` branch where we prepare
-the next version. The provider uses strict `SemVer <https://semver.org>`_ versioning policy. Depending on
-the scope of the change, Provider will get ''MAJOR'' version upgrade when there are
-breaking changes, ``MINOR`` version upgrade when there are new features or ``PATCHLEVEL`` version upgrade
-when there are only bug fixes (including security bugfixes) - and this is the only version that receives
-security fixes by default, so you should upgrade to latest version of the provider if you want to receive
-all released security fixes.
-
-The only exception to that rule is when we have a critical security fix and good reason to provide an
-out-of-band release for the provider, in which case stakeholders in the provider might decide to cherry-pick
-and prepare a branch for an older version of the provider following the
-`mixed governance model <https://github.com/apache/airflow/blob/main/PROVIDERS.rst#mixed-governance-model>`_
-and requires interested parties to cherry-pick and test the fixes.
+.. include:: ../exts/includes/security.rst

docs/apache-airflow-providers-apache-cassandra/security.rst

@@ -1,4 +1,3 @@
-
  .. Licensed to the Apache Software Foundation (ASF) under one
     or more contributor license agreements.  See the NOTICE file
     distributed with this work for additional information
@@ -16,23 +15,4 @@
     specific language governing permissions and limitations
     under the License.
 
-Releasing security patches
---------------------------
-
-Airflow providers are released independently from Airflow itself and the information about vulnerabilities
-is published separately. You can upgrade providers independently from Airflow itself, following the
-instructions found in :doc:`apache-airflow:installation/installing-from-pypi`.
-
-When we release Provider version, the development is always done from the ``main`` branch where we prepare
-the next version. The provider uses strict `SemVer <https://semver.org>`_ versioning policy. Depending on
-the scope of the change, Provider will get ''MAJOR'' version upgrade when there are
-breaking changes, ``MINOR`` version upgrade when there are new features or ``PATCHLEVEL`` version upgrade
-when there are only bug fixes (including security bugfixes) - and this is the only version that receives
-security fixes by default, so you should upgrade to latest version of the provider if you want to receive
-all released security fixes.
-
-The only exception to that rule is when we have a critical security fix and good reason to provide an
-out-of-band release for the provider, in which case stakeholders in the provider might decide to cherry-pick
-and prepare a branch for an older version of the provider following the
-`mixed governance model <https://github.com/apache/airflow/blob/main/PROVIDERS.rst#mixed-governance-model>`_
-and requires interested parties to cherry-pick and test the fixes.
+.. include:: ../exts/includes/security.rst

docs/apache-airflow-providers-apache-drill/security.rst

@@ -1,4 +1,3 @@
-
  .. Licensed to the Apache Software Foundation (ASF) under one
     or more contributor license agreements.  See the NOTICE file
     distributed with this work for additional information
@@ -16,23 +15,4 @@
     specific language governing permissions and limitations
     under the License.
 
-Releasing security patches
---------------------------
-
-Airflow providers are released independently from Airflow itself and the information about vulnerabilities
-is published separately. You can upgrade providers independently from Airflow itself, following the
-instructions found in :doc:`apache-airflow:installation/installing-from-pypi`.
-
-When we release Provider version, the development is always done from the ``main`` branch where we prepare
-the next version. The provider uses strict `SemVer <https://semver.org>`_ versioning policy. Depending on
-the scope of the change, Provider will get ''MAJOR'' version upgrade when there are
-breaking changes, ``MINOR`` version upgrade when there are new features or ``PATCHLEVEL`` version upgrade
-when there are only bug fixes (including security bugfixes) - and this is the only version that receives
-security fixes by default, so you should upgrade to latest version of the provider if you want to receive
-all released security fixes.
-
-The only exception to that rule is when we have a critical security fix and good reason to provide an
-out-of-band release for the provider, in which case stakeholders in the provider might decide to cherry-pick
-and prepare a branch for an older version of the provider following the
-`mixed governance model <https://github.com/apache/airflow/blob/main/PROVIDERS.rst#mixed-governance-model>`_
-and requires interested parties to cherry-pick and test the fixes.
+.. include:: ../exts/includes/security.rst

docs/apache-airflow-providers-apache-druid/security.rst

@@ -1,4 +1,3 @@
-
  .. Licensed to the Apache Software Foundation (ASF) under one
     or more contributor license agreements.  See the NOTICE file
     distributed with this work for additional information
@@ -16,23 +15,4 @@
     specific language governing permissions and limitations
     under the License.
 
-Releasing security patches
---------------------------
-
-Airflow providers are released independently from Airflow itself and the information about vulnerabilities
-is published separately. You can upgrade providers independently from Airflow itself, following the
-instructions found in :doc:`apache-airflow:installation/installing-from-pypi`.
-
-When we release Provider version, the development is always done from the ``main`` branch where we prepare
-the next version. The provider uses strict `SemVer <https://semver.org>`_ versioning policy. Depending on
-the scope of the change, Provider will get ''MAJOR'' version upgrade when there are
-breaking changes, ``MINOR`` version upgrade when there are new features or ``PATCHLEVEL`` version upgrade
-when there are only bug fixes (including security bugfixes) - and this is the only version that receives
-security fixes by default, so you should upgrade to latest version of the provider if you want to receive
-all released security fixes.
-
-The only exception to that rule is when we have a critical security fix and good reason to provide an
-out-of-band release for the provider, in which case stakeholders in the provider might decide to cherry-pick
-and prepare a branch for an older version of the provider following the
-`mixed governance model <https://github.com/apache/airflow/blob/main/PROVIDERS.rst#mixed-governance-model>`_
-and requires interested parties to cherry-pick and test the fixes.
+.. include:: ../exts/includes/security.rst

docs/apache-airflow-providers-apache-flink/security.rst

@@ -1,4 +1,3 @@
-
  .. Licensed to the Apache Software Foundation (ASF) under one
     or more contributor license agreements.  See the NOTICE file
     distributed with this work for additional information
@@ -16,23 +15,4 @@
     specific language governing permissions and limitations
     under the License.
 
-Releasing security patches
---------------------------
-
-Airflow providers are released independently from Airflow itself and the information about vulnerabilities
-is published separately. You can upgrade providers independently from Airflow itself, following the
-instructions found in :doc:`apache-airflow:installation/installing-from-pypi`.
-
-When we release Provider version, the development is always done from the ``main`` branch where we prepare
-the next version. The provider uses strict `SemVer <https://semver.org>`_ versioning policy. Depending on
-the scope of the change, Provider will get ''MAJOR'' version upgrade when there are
-breaking changes, ``MINOR`` version upgrade when there are new features or ``PATCHLEVEL`` version upgrade
-when there are only bug fixes (including security bugfixes) - and this is the only version that receives
-security fixes by default, so you should upgrade to latest version of the provider if you want to receive
-all released security fixes.
-
-The only exception to that rule is when we have a critical security fix and good reason to provide an
-out-of-band release for the provider, in which case stakeholders in the provider might decide to cherry-pick
-and prepare a branch for an older version of the provider following the
-`mixed governance model <https://github.com/apache/airflow/blob/main/PROVIDERS.rst#mixed-governance-model>`_
-and requires interested parties to cherry-pick and test the fixes.
+.. include:: ../exts/includes/security.rst

docs/apache-airflow-providers-apache-hdfs/security.rst

@@ -1,4 +1,3 @@
-
  .. Licensed to the Apache Software Foundation (ASF) under one
     or more contributor license agreements.  See the NOTICE file
     distributed with this work for additional information
@@ -16,23 +15,4 @@
     specific language governing permissions and limitations
     under the License.
 
-Releasing security patches
---------------------------
-
-Airflow providers are released independently from Airflow itself and the information about vulnerabilities
-is published separately. You can upgrade providers independently from Airflow itself, following the
-instructions found in :doc:`apache-airflow:installation/installing-from-pypi`.
-
-When we release Provider version, the development is always done from the ``main`` branch where we prepare
-the next version. The provider uses strict `SemVer <https://semver.org>`_ versioning policy. Depending on
-the scope of the change, Provider will get ''MAJOR'' version upgrade when there are
-breaking changes, ``MINOR`` version upgrade when there are new features or ``PATCHLEVEL`` version upgrade
-when there are only bug fixes (including security bugfixes) - and this is the only version that receives
-security fixes by default, so you should upgrade to latest version of the provider if you want to receive
-all released security fixes.
-
-The only exception to that rule is when we have a critical security fix and good reason to provide an
-out-of-band release for the provider, in which case stakeholders in the provider might decide to cherry-pick
-and prepare a branch for an older version of the provider following the
-`mixed governance model <https://github.com/apache/airflow/blob/main/PROVIDERS.rst#mixed-governance-model>`_
-and requires interested parties to cherry-pick and test the fixes.
+.. include:: ../exts/includes/security.rst

docs/apache-airflow-providers-apache-hive/security.rst

@@ -1,4 +1,3 @@
-
  .. Licensed to the Apache Software Foundation (ASF) under one
     or more contributor license agreements.  See the NOTICE file
     distributed with this work for additional information
@@ -16,23 +15,4 @@
     specific language governing permissions and limitations
     under the License.
 
-Releasing security patches
---------------------------
-
-Airflow providers are released independently from Airflow itself and the information about vulnerabilities
-is published separately. You can upgrade providers independently from Airflow itself, following the
-instructions found in :doc:`apache-airflow:installation/installing-from-pypi`.
-
-When we release Provider version, the development is always done from the ``main`` branch where we prepare
-the next version. The provider uses strict `SemVer <https://semver.org>`_ versioning policy. Depending on
-the scope of the change, Provider will get ''MAJOR'' version upgrade when there are
-breaking changes, ``MINOR`` version upgrade when there are new features or ``PATCHLEVEL`` version upgrade
-when there are only bug fixes (including security bugfixes) - and this is the only version that receives
-security fixes by default, so you should upgrade to latest version of the provider if you want to receive
-all released security fixes.
-
-The only exception to that rule is when we have a critical security fix and good reason to provide an
-out-of-band release for the provider, in which case stakeholders in the provider might decide to cherry-pick
-and prepare a branch for an older version of the provider following the
-`mixed governance model <https://github.com/apache/airflow/blob/main/PROVIDERS.rst#mixed-governance-model>`_
-and requires interested parties to cherry-pick and test the fixes.
+.. include:: ../exts/includes/security.rst