I will be working this week to make some of the last changes - based
on the summary above and plan to make the RC of backport operators
still this week - hopefully with voting of PMC it is going to be
released officially next week.

On Mon, Apr 27, 2020 at 4:26 PM Kaxil Naik <[email protected]> wrote:
>
> 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.
> >>
> >>



-- 

Jarek Potiuk
Polidea | Principal Software Engineer

M: +48 660 796 129

Reply via email to