potiuk commented on code in PR #37058: URL: https://github.com/apache/airflow/pull/37058#discussion_r1472667511
########## airflow/providers/common/io/xcom/__init__.py: ########## @@ -0,0 +1,37 @@ +# 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. +from __future__ import annotations + +import packaging.version + +__all__ = ["__version__"] + +__version__ = "1.3.0" + + +try: + from airflow import __version__ as airflow_version +except ImportError: + from airflow.version import version as airflow_version + +if packaging.version.parse(packaging.version.parse(airflow_version).base_version) < packaging.version.parse( + "2.9.0" +): + raise RuntimeError( + f"The package `apache-airflow-providers-common-io:{__version__}` needs Apache Airflow 2.9.0+" Review Comment: Yeah. Better to keep those in one PR. I think - contrary to natural thinking - this is precisely the thing that is better when you have monorepo - that you **can** introduce changes to multiple independent parts at the same time, and while resulting setup is more complex (because you have to manage back-compatibility and dependencies as we do here) generally development of it is quite a bit easier, because you effectively work on a combined change even if your change comes to two different components within the monorepo. And it's not a problem at all in our release process either - there is completely separate release process and marking "PR" as being part either of the provider or or airflow release - the same PR will appear in both at some point of time and we can literally decide at the last moment before relasing provider whethere we mark the change also cherry-pickable to 2.8 branch. This is the TRUE power of monorepo - development of such combined features is WAY easier. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
