Agree with Kamil here. We should just adjust the versioning of the docker provider and bump the Minor version to indicate New Feature.
To XD's question - we can release a patch version in that minor version series for Docker Provider if we find a critical fix. Regards, Kaxil On Thu, Sep 30, 2021, 04:03 Jarek Potiuk <[email protected]> wrote: > >> I have no strong opinion on this, but would like to have clarification on >> one question: I understand you highlighted there is no changes nor fixes in >> the provider, but what if in the future we need to fix something for the >> “classic” operator which may still be used in Airflow 2.1 or even lower >> version installations? How will releases etc. be managed in such cases? >> > > Yep. Good question. This is about the only "potential" issue - currently > we have no process for that as we've never had to do it. However it is > always possible to do it if and when we need it. If we find that there is a > critical fix for Docker Provider that we would need to fix, we can always > branch-off from the last released version that works for 2.1 and > cherry-pick and release a patched version. > > We did not see a need for that so far. We released all providers when we > released 2.1.0 which are 2.1+ only (because of apply_defaults) and so far > there was not a case where anyone raised a need to release any bugfix for > previous versions. With our SemVer approach anyone should be "SAFE" > migrating to newer version of Airflow (even 2.2) as they are all supposed > to be backwards compatible, so I think our approach should be "If you need > anything that we release for the DockerProvider in the future - migrate to > 2.2. But this is a "default" approach I think and I see the case of a > really critical issue that will result in releasing a patchlevel version > for the previous release. > > Again - we have not done that yet, and we want to avoid it for as long as > we can, but there is nothing (except the overhead on cherry-picking and > releasing it) to prevent us from doing so. We have all history, tags, > changelogs and mechanisms to selectively release only one provider if > needed. But I think it should be really Ad-Hoc and when we REALLY REALLY > need it. > > J. > > I may have misunderstood or missed something, and be asking a dumb >> question. Please correct me in that case. >> >> Thanks! >> >> >> XD >> >> On Wed, Sep 29, 2021 at 22:15 Jarek Potiuk <[email protected]> wrote: >> >>> Hello Everyone, >>> >>> I am just about to release the September Providers, but Kamil raised a >>> valid concern and he convinced me that it might be a problem if we release >>> a new Docker Provider with minimum airflow version 2.1. >>> >>> The new provider has the new "Docker Decorator" feature which will be >>> available only in 2.2. But other than that - it is backwards compatible - >>> so you could install it on Airflow 2.1 and have the "classic" operator >>> work. But if you try to use the decorator, you will be able to write a Dag >>> with this decorator, but it simply won't work (and you will have no message >>> about it). >>> >>> The Docker Provider has no other changes nor fixes. >>> >>> I am tempted (and quite convinced) to increase the min airflow version >>> of the Docker Provider to 2.2 so that it can be only installed there (and >>> we make it ready for the 2.2 release). >>> >>> Does anyone have a strong opinion on that ? >>> >>> J. >>> >>> >>> >>>
