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),