vikramkoka commented on a change in pull request #14132: URL: https://github.com/apache/airflow/pull/14132#discussion_r575733415
########## 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 Review comment: I think this statement is controversial enough that some explanation would be useful. I realize that this is intended to make it is simpler for people to migrate to a major version without being confused by all the "new features", but that is only because of being at the dev call when you expressed it :) ---------------------------------------------------------------- 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]
