This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/main by this push:
new 1edd00cb17 Add description on what goes into the next release (#35245)
1edd00cb17 is described below
commit 1edd00cb171793a3dd9878f80182b61f7527f314
Author: Jarek Potiuk <ja...@potiuk.com>
AuthorDate: Mon Oct 30 11:34:24 2023 +0100
Add description on what goes into the next release (#35245)
---
README.md | 47 +++++++++++++++++++++++++++++++++++++++++++++++
generated/PYPI_README.md | 3 +++
2 files changed, 50 insertions(+)
diff --git a/README.md b/README.md
index b3dd427627..a53ff5bbf5 100644
--- a/README.md
+++ b/README.md
@@ -62,6 +62,7 @@ Use Airflow to author workflows as directed acyclic graphs
(DAGs) of tasks. The
- [Contributing](#contributing)
- [Who uses Apache Airflow?](#who-uses-apache-airflow)
- [Who maintains Apache Airflow?](#who-maintains-apache-airflow)
+- [What goes into the next release?](#what-goes-into-the-next-release)
- [Can I use the Apache Airflow logo in my
presentation?](#can-i-use-the-apache-airflow-logo-in-my-presentation)
- [Airflow merchandise](#airflow-merchandise)
- [Links](#links)
@@ -422,6 +423,7 @@ By default, we should not upper-bound dependencies for
providers, however each p
might decide to add additional limits (and justify them with comment).
<!-- START Contributing, please keep comment here to allow auto update of PyPI
readme.md -->
+
## Contributing
Want to help build Apache Airflow? Check out our [contributing
documentation](https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst).
@@ -430,6 +432,7 @@ Official Docker (container) images for Apache Airflow are
described in [IMAGES.r
<!-- END Contributing, please keep comment here to allow auto update of PyPI
readme.md -->
<!-- START Who uses Apache Airflow, please keep comment here to allow auto
update of PyPI readme.md -->
+
## Who uses Apache Airflow?
More than 400 organizations are using Apache Airflow
@@ -437,6 +440,7 @@ More than 400 organizations are using Apache Airflow
<!-- END Who uses Apache Airflow, please keep comment here to allow auto
update of PyPI readme.md -->
<!-- START Who maintains Apache Airflow, please keep comment here to allow
auto update of PyPI readme.md -->
+
## Who maintains Apache Airflow?
Airflow is the work of the
[community](https://github.com/apache/airflow/graphs/contributors),
@@ -446,6 +450,49 @@ If you would like to become a maintainer, please review
the Apache Airflow
[committer
requirements](https://github.com/apache/airflow/blob/main/COMMITTERS.rst#guidelines-to-become-an-airflow-committer).
<!-- END Who maintains Apache Airflow, please keep comment here to allow auto
update of PyPI readme.md -->
+
+## What goes into the next release?
+
+Often you will see an issue that is assigned to specific milestone with
Airflow version, or PR that gets merged
+to the main branch and you might wonder which release the merged PR will be
released in or which release the
+issue will be fixed in. The answer to it is as usual - it depends. The answer
is different for PRs and Issues.
+
+To add a bit of context, ee are following the [Semver](https://semver.org/)
versioning scheme as described in
+[Airflow release
process](https://airflow.apache.org/docs/apache-airflow/stable/release-process.html).
More
+details are explained in detail in this README in [Semantic
versioning](#semantic-versioning) chapter, but
+in short, we have `MAJOR.MINOR.PATCH` versions of Airflow, where `MAJOR`
version is incremented when there
+are breaking changes, `MINOR` version is incremented when there are new
features added, and `PATCH` version
+is incremented when there are only bug-fixes and doc-only changes.
+
+Generally we release `MINOR` versions of Airflow from a branch that is named
after the MINOR version. For example
+`2.7.*` releases are released from `v2-7-stable` branch, `2.8.*` releases are
released from `v2-8-stable`
+branch, etc.
+
+Most of the time in our release cycle, when the branch for next `MINOR` branch
is not yet created, all
+PRs merged to `main` (unless they get reverted), will find their way to the
next `MINOR` release. For example
+if the last release is `2.7.0` or `2.7.1` and `v2-8-stable` branch is not
created yet, the next `MINOR` release
+is `2.8.0` and all PRs merged to main will be released in `2.8.0`. There is a
brief period of time when we
+cut a new `MINOR` release branch and prepare alpha, beta, RC candidates for
the `2.NEXT_MINOR.0` version
+where PRs merged to main will only be released in the following `MINOR`
release.
+
+However, some PRs (bug-fixes and doc-only changes) when merged, can be
cherry-picked to current `MINOR` branch
+and released in the next `PATCHLEVEL` release - for example when the last
released version from `v2-7-stable`
+branch is `2.7.2`. Some of the PRs from main can be marked as `2.7.3`
milestone by committers and attempt by the
+release manager to cherry-pick them is made. If successful, they will be
released in `2.7.3`. The final
+decision about cherry-picking is made by the release manager.
+
+Marking issues with a milestone is a bit different. Maintainers do not mark
issues with a milestone usually,
+normally they are only marked in PRs. If PR linked to the issue (and "fixing
it") gets merged and released
+in a specific version following the process described above, the issue will be
automatically closed, no
+milestone will be set for the issue, you need to check the PR that fixed the
issue to see which version
+it was released in. However sometimes maintainers mark issues with specific
milestone, which means that the
+issue is important to become a candidate to take a look when the release is
being prepared. Since this is an
+Open-Source project, where basically all contributors volunteer their time,
there is no guarantee that specific
+issue will be fixed in specific version. We do not want to hold the release
because some issue is not fixed,
+so in such case release manager will reassign such unfixed issues to the next
milestone in case they are not
+fixed in time for the current release. Therefore, the milestone for issue is
more of an intent that it should be
+looked at, than promise it will be fixed in the version.
+
## Can I use the Apache Airflow logo in my presentation?
Yes! Be sure to abide by the Apache Foundation [trademark
policies](https://www.apache.org/foundation/marks/#books) and the Apache
Airflow
[Brandbook](https://cwiki.apache.org/confluence/display/AIRFLOW/Brandbook). The
most up-to-date logos are found in [this
repo](https://github.com/apache/airflow/tree/main/docs/apache-airflow/img/logos/)
and on the Apache Software Foundation
[website](https://www.apache.org/logos/about.html).
diff --git a/generated/PYPI_README.md b/generated/PYPI_README.md
index 477db1e075..c5d8f28784 100644
--- a/generated/PYPI_README.md
+++ b/generated/PYPI_README.md
@@ -154,17 +154,20 @@ and our official source code releases:
Following the ASF rules, the source packages released must be sufficient for a
user to build and test the
release provided they have access to the appropriate platform and tools.
+
## Contributing
Want to help build Apache Airflow? Check out our [contributing
documentation](https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst).
Official Docker (container) images for Apache Airflow are described in
[IMAGES.rst](https://github.com/apache/airflow/blob/main/IMAGES.rst).
+
## Who uses Apache Airflow?
More than 400 organizations are using Apache Airflow
[in the wild](https://github.com/apache/airflow/blob/main/INTHEWILD.md).
+
## Who maintains Apache Airflow?
Airflow is the work of the
[community](https://github.com/apache/airflow/graphs/contributors),
