vikramkoka commented on a change in pull request #14132: URL: https://github.com/apache/airflow/pull/14132#discussion_r575733188
########## File path: docs/apache-airflow/release-process.rst ########## @@ -0,0 +1,61 @@ + .. 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 + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + .. http://www.apache.org/licenses/LICENSE-2.0 + + .. Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. + +========================= +Airflow's release process +========================= + +Since Airflow 2.0.0 the release numbering works as follows: + +- Versions are numbered in the form X.Y.Z. +- X is the major version number. +- Y is the minor version number, also called the *feature release* version number. +- Z is the patch number, which is incremented for bugfix and security releases- Before every new release, we’ll make a release candidate available, and often alpha or beta release too. These are of the form X.Y.Z alpha/beta/rc N, which means the Nth alpha/beta/release candidate of version X.Y.Z + +In git, each minor version will have its own branch, called ``vX-Y-stable`` where bugfix/security releases will be issued from. + +Each Airflow release will also have a tag in git indicating its version number, signed with the release manager's key. Additionally, each release series has its own branch, called stable/A.B.x, and bugfix/security releases will be issued from those branches. + +.. glossary:: + + Major release + Major releases (X.0.0, X+1.0.0 etc.) indicate a backwards-incompatible change. + + These releases do not happen with any regular interval or on any predictable schedule. + + Major versions should aim to not introduce any major new features, instead it should just be the removal + of previously deprecated features. + + Feature releases + Feature releases (X.Y.0, X.Y+1.0, etc.) will happen roughly every two months – see release process for + details. These releases will contain new features, improvements to existing features, and such. + + Patch releases + Patch releases (X.Y.Z, X.Y.Z+1, etc.) will happen, on an as-needed basis, as issues are reported and + fixed. + + These releases will be 100% compatible with the associated feature release, unless this is + impossible for security reasons or to prevent data loss. So the answer to "should I upgrade to the + latest patch release?" will always be "yes." + + The only exception is when a security or data loss issue can’t be fixed without breaking Review comment: ```suggestion The only exception to the above with respect to 100% backwards compatibility is when a security or data loss issue can’t be fixed without breaking ``` ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
