The following are the things that we (Me, Ash & Jarek) agree upon for the Backport Packages.
- Our Release Guide: https://cwiki.apache.org/confluence/display/AIRFLOW/Releasing+Airflow - This has details (or links to other docs) on how to create your GPG KEYS and upload them to https://dist.apache.org/repos/dist/release/airflow/KEYS. And has the details of the actual release process. Feel free to create a separate section (or a Subpage) for releasing the Backport package. - Our normal RC Voting rules apply - Versioning: *CALVER* (YYYY-MM-DD) - Release backport packages for all the providers for the first one. After that, they can be released individually - Docs: The Readme inside each Provider backport package will contain details about the list of new Operators/Hooks/Secrets etc - ReadtheDocs: Create a new page that shows all the Backport Packages that were released with Changelogs (We should not add this page on airflow.apache.org doc site, so maybe add an RTD env var to ignore - ???) - Have 'backport' in the name (e.g apache-airflow-backport-provider-google) of the final release candidate and the package to future-proof us if we ever separate the provides folder to separate repos - Create separate folder for each provider downloads.apache.org/airflow/backport-providers/$provider/$ver/$x.whl - To get files into downloads.apache.org we do it via SVN, and we should obviously upload it to dev/ first (which is what your release guide says to do) - We will have a single Git Tag for each Backport Release (e.g backport-provider-2020-04-27) can have multiple providers released under it but a Single Git Tag I have pasted the notes here if anyone has a different opinion on any of the points above please let us know. Regards, Kaxil On Mon, Apr 20, 2020 at 3:47 PM Kaxil Naik <[email protected]> wrote: > I still disagree with that, at least in the case of Operator related bugs. > But anyways that is not that important 😁 or doesn't really matter. > > Just summarizing my opinion on backport packages: > > - CALVER makes sense for versioning. > - Let's not make "system-tests" hard criteria to release backport > packages. It is ideal if we have them, but even if we don't we should still > release them if they have sufficient unit-tests. > > Regards, > Kaxil > > > On Mon, Apr 20, 2020 at 3:41 PM Jarek Potiuk <[email protected]> > wrote: > >> >>> Well, "bug" and "features" are separate things. If there is a broken code >>> or bug in Airflow 1.10.*, we should fix it was my point :) >>> >> Well. We all know this one (not sure if the mailing list passes so link >> to share: https://programowo.net/photo/21/ >> >> Sometimes it's really hard to distinguish ;). >> >> But yeah. Seriously - we do fix bugs that are fixable in 1.10 :). And we >> do not shy away from that. >> >>
