Re: [DISCUSS] Guidelines for Releasing Providers packages

I agree with *Batch vs Ad-hoc *and *Frequency.* For doc-only changes, I would prefer NOT to change the version. Primarily because of the end user perspective, as was articulated earlier in the thread. Best regards, Vikram On Tue, Mar 9, 2021 at 6:05 PM Jarek Potiuk wrote: > Fully agree batch

Re: [DISCUSS] Major Version should contain new features or just removal of deprecation?

I love the thoughtful discussion. I am in favour of (b), because that is the "general understanding" of Semantic Versioning. On Tue, Mar 9, 2021 at 6:14 PM Kaxil Naik wrote: > Interesting points, reminds me of this thread: > https://github.com/semver/semver/issues/411#issuecomment-347050750 😄

Re: Voting and release process for providers

TL;DR; My very, very strong preference goes for one email which is effectively N votes for N packages we release. I actually think we are not able to efficiently follow up and manage 1-vote for email for ~20 or so packages we are going to release every month. I think we should just refer back to w

Re: [DISCUSS] Major Version should contain new features or just removal of deprecation?

Interesting points, reminds me of this thread: https://github.com/semver/semver/issues/411#issuecomment-347050750 😄 Some comments / suggestions from the commenters on that post which I find interesting (both of which support one or the other option we are discussing). 1) Use BREAKING.FEATURE.PAT

Re: [DISCUSS] Guidelines for Releasing Providers packages

Fully agree batch and ad-hoc approach as well as with the frequency. For docs-only changes I think -post release in PyPI is not a good idea. It does not follow semver (https://semver.org/). The only way you can extend the number in SEMVER is for pre-releases: > A pre-release version MAY be denote

Re: [DISCUSS] Major Version should contain new features or just removal of deprecation?

Very slight preference for b) for the marketing value but a) has some nice properties too and if we have enough support for a) I would also follow "remove deprecated features only". I do not think we break semver with a) : https://semver.org/. Major version MAY (but not MUST) include minor and pa

Re: [VOTE] Release apache-airflow-upgrade-check 1.3.0 from 1.3.0rc1

Correction: The vote will last until Friday 12th March 23:40 UTC Had February instead of March in the first email. On Tue, Mar 9, 2021, 23:38 Kaxil Naik wrote: > Hey all, > > This calls for the release of a new dist: *apache-airflow-upgrade-check*, > version 1.3.0. This represents the content

[VOTE] Release apache-airflow-upgrade-check 1.3.0 from 1.3.0rc1

Hey all, This calls for the release of a new dist: *apache-airflow-upgrade-check*, version 1.3.0. This represents the contents of the airflow/upgrade/ tree (plus a few supporting files) as a separate dist. This code is based on the v1-10-stable branch, the git tag is https://github.com/apache/air

Re: [VOTE] Airflow Providers - release prepared 2021-03-08

+1 (binding) then, thanks for explaining! Tomek On Tue, 9 Mar 2021 at 21:06, Jarek Potiuk wrote: > Thanks for being so thorough :). This is fine (except the -bin prefix > mentioned in the email template). Good eye. The "-bin" prefix was removed > compared to the Airflow release, because we do n

Re: [VOTE] Airflow Providers - release prepared 2021-03-08

Thanks for being so thorough :). This is fine (except the -bin prefix mentioned in the email template). Good eye. The "-bin" prefix was removed compared to the Airflow release, because we do not have separate src vs. bin releases for providers (I will fix it for the next time). For the providers p

Re: [VOTE] Airflow Providers - release prepared 2021-03-08

According to SVN check step there should be 36 (4 x 9) files. I see all whl files but instead of: -bin-tar.gz + .asc + .sha512 (one set of files per provider) I see: -tar.gz + .asc + .sha512 And no source.tar.gz + .asc + .sha512 (one set of files) [unless we count the ones from backports). Is th

Re: [DISCUSS] Guidelines for Releasing Providers packages

I'm ok with batch and ad-hoc approach as well as with the frequency. In case of docs-only changes I second what Ash proposed - let's not alter the version. 100% of functionality is the same so users are not affected and there's no need to update. As per testing I agree that E2E testing of all pro

Re: [DISCUSS] Major Version should contain new features or just removal of deprecation?

I'm also in favor of *b)*. If we expect that new features may confuse users then maybe we should adopt a rule that when a feature is introduced it is protected by the feature flag and is not enabled by default. Of course this may not always be possible or may create even more confusion. Cheers, T

Re: [DISCUSS][AIP-39] Richer (and pluggable) schedule_interval on DAGs

Hi Ash and all, What do people think of this? Worth it? Too complex to reason about what > context variables might exist as a result? I think I wouldn't worry about it right now or maybe not as part of this AIP. Currently, in one of the Github Issue, a user mentioned that it is not straightforw

Re: [Meeting Notes] Airflow Dev Call - 3 March 2021

Thanks Kaxil for the notes! Tomek On Mon, 8 Mar 2021 at 22:41, Kaxil Naik wrote: > > Hi all, > > Here are the notes from our Airflow dev call last week. Thank you to all who > joined the call. > Here is a quick summary of the call. > > Summary Notes: > > Add a policy document around all our Pol

Re: Voting and release process for providers

+1 -- I think users can pick and choose which providers to test and vote on. And since each vote would be in a separate email, a single provider bug in a particular provider won't derail conversation. Regards, Kaxil On Tue, Mar 9, 2021, 11:38 Kaxil Naik wrote: > +1 > > On Sat, Mar 6, 2021, 21:3

Re: Voting and release process for providers

+1 On Sat, Mar 6, 2021, 21:33 Ash Berlin-Taylor wrote: > Just for absolutely clarity here: my -1 has nothing to do with the vote on > the release, merely against adopting the proposed policy after this > release/current set of votes. > > -a > > On 4 March 2021 11:04:13 GMT, Ash Berlin-Taylor wr

Fwd: Call for Presentations for ApacheCon 2021 now open

Hi folk, On the backs of the resounding success from last year's, ApacheCon@Home will be online, and again, we'll be featuring the (Software) Integration track. I'm the chair of the Integration track at ApacheCon@Home. And I'd like to invite folk from the Apache Airflow community to participate by

Re: [DISCUSS] Guidelines for Releasing Providers packages

For doc-only changes there is one extra thing to decide: Should we do it as a patch version (1.0.2 etc) or as a "post" release? Python packages have this concept: > Some projects use post-releases to address minor errors in a final re

Fwd: Call for Presentations for ApacheCon 2021 now open

Hi folk, On the backs of the resounding success from last year's, ApacheCon@Home will be online, and again, we'll be featuring the (Software) Integration track. I'm the chair of the Integration track at ApacheCon@Home. And I'd like to invite folk from the Apache Airflow community to participate by

Re: [DISCUSS] Major Version should contain new features or just removal of deprecation?

To me it should be *(b)*, especially given we intend to follow SemVar. People would have specific expectations on MAJOR/MINOR/PATCH if we claim SemVar is followed. *(a)* would cause confusion in such context. XD On Tue, Mar 9, 2021 at 12:43 AM Kaxil Naik wrote: >