Yep. I think immediate deprecation is the way to go.
Those who care will change. For those who don't care - well, they don't
care so it doesn't matter.
On Sat, Aug 6, 2022 at 9:10 PM Daniel Standish
wrote:
> It's not addressed explicitly in the vote. Personally I think we should
> add a deprec
It's not addressed explicitly in the vote. Personally I think we should
add a deprecation warning immediately. I understand that there is the
thought to "give users time to make the change" before adding the warning.
But deprecation warnings are probably the most effective, most relied upon
mecha
One question: are we deprecating the existing parameters straight away or
leaving it without a warning for one release? (I think someone talked about
that at one point)
On 6 August 2022 19:46:02 BST, Daniel Standish
wrote:
>Well, thanks for forcing us to make the case :)
>
>I'll initiate a laz
Well, thanks for forcing us to make the case :)
I'll initiate a lazy consensus "vote"
On Fri, Aug 5, 2022 at 1:01 PM Vikram Koka
wrote:
> Fair points all.
> I withdraw my objection and agree with the consolidation proposal.
>
> Vikram
>
>
> On Fri, Aug 5, 2022 at 10:06 AM Jarek Potiuk wrote:
Fair points all.
I withdraw my objection and agree with the consolidation proposal.
Vikram
On Fri, Aug 5, 2022 at 10:06 AM Jarek Potiuk wrote:
> Let me also add to why I think we should consolidate to one param::
>
> * "schedule_interval"
> * "schedule_on"
> * "timetable"
>
> Imagine you are a
Let me also add to why I think we should consolidate to one param::
* "schedule_interval"
* "schedule_on"
* "timetable"
Imagine you are a new user coming to Airflow.
Do you immediately recognise which one is which ? Do you see what the
difference is?
* "Schedule_on" = "Every Sunday" is equally
@Vikram, yeah, I understand that concern. Making a breaking change is
something we shouldn't do carelessly, without consideration, without good
reason. But I think we have a good reason here.
Deprecations are somewhat regular in airflow. In 2.0 we moved a lot of
imports. We also changed the CL
I'm not in favor of reusing `schedule_interval` for datasets (or folding
`timetable` into it either), primarily because it doesn't feel like a good
name to describe what it does. If we don't have the appetite to
consolidate, my vote is we stick with 3 separate params. So preferably #1,
if not then
I'll just +1 that IMO a UI reminder is a great option.
2.3.0 added an alert when robots.txt was being scanned, which was great,
because I ignored it for a while, but eventually caved and looked into it.
This I would see as more of the same. I currently get loads of warnings
about things in my conf
Hi Daniel,
I completely agree with wanting to consolidate, but I am very concerned
about people needing to change their existing code.
As Ping and Felix also said, I worry that people ignore deprecation
warnings, especially since the original code authors don't really look at
logs or other pipelin
I agree with those (including myself) who have suggested that it would be
great to have a deprecation fix tool.
I also think that UI notifications would be valuable. Another option would
be to provide a less intrusive indicator somewhere (like when chrome lets
you know you need to update), and th
I know we are distracting a bit from the main subject, but I think it's
worth it.
I think this is a fact of life that people don't remove deprecations. But
we have a choice of "not doing anything about it" and complaining. Or doing
something that might improve it.
I usually err on the side of "do
Hi Ping,
I had this idea about auto-fixing deprecation warnings too when I started the
airflint project.
I totally agree with what you said that often people ignore these warnings and
therefore a cli tool would come in very handy. It could look similar to the
airflint project and also be based
Hi Daniel,
+1 for ‘schedule' and thanks for bringing this up.
I agree with Vikram, we should be very careful about deprecating existing
params even if we have warnings around it. Not sure if this is a general
case, but I notice that people ignore warnings all the time until it starts
to break. Th
In case you forgot about us @Vikram, gentle nudge
On Mon, Aug 1, 2022 at 8:40 AM Daniel Standish <
daniel.stand...@astronomer.io> wrote:
> Well, this is a discussion thread, so let's discuss!
>
> Vikram, what kind of implications are you thinking of? Maybe you could
> provide a little more detai
Well, this is a discussion thread, so let's discuss!
Vikram, what kind of implications are you thinking of? Maybe you could
provide a little more detail about your concerns?
There are certainly alternatives, and of course each of them has tradeoffs.
Here are the options I see:
1. consolidate t
-1 from me.
Though I agree in principle with the idea of consolidation, I don't think
we should be doing this yet until we understand the implications
completely.
I am really not in favor of deprecation of the existing params, unless
there is really no alternative.
On Fri, Jul 29, 2022 at 2:37 P
So far, seems all in favor.
I will just highlight, in case it's not clear when we release this
(presumably 2.4), basically every single dag in existence will start
emitting deprecation warnings, and prior to 3.0, basically every dag in
existence will need to be updated.
Thankfully, for most p
+1 to consolidating and "schedule".
On Fri, Jul 29, 2022, 10:12 PM Drew Hubl
wrote:
> +1 for ‘schedule', and another +1 to the importance of consolidating to
> one being more important than the name of that one
>
> On Jul 29, 2022, at 1:58 PM, Josh Fell
> wrote:
>
> Consolidating to a single sc
+1 for ‘schedule', and another +1 to the importance of consolidating to one
being more important than the name of that one
> On Jul 29, 2022, at 1:58 PM, Josh Fell
> wrote:
>
> Consolidating to a single scheduling parameter is a big +1 from me.
> `schedule` seems like a nice catch-all.
>
> O
Consolidating to a single scheduling parameter is a big +1 from me.
`schedule` seems like a nice catch-all.
On Fri, Jul 29, 2022 at 9:10 AM Jed Cunningham
wrote:
> +1 on moving to a single `schedule` param.
>
+1 on moving to a single `schedule` param.
I agree that the schedule params should be consolidated. I don't think it
would be bad to coalesce around schedule_interval instead of making a new
one. Cron expressions are already not really "intervals", and I think that
asking the overwhelming majority of DAGs to change a param name is likely
no
+1 for new "schedule" param to rule them all and deprecate the rest.
On Wed, Jul 27, 2022 at 10:36 PM Daniel Standish
wrote:
> As of airflow 2.3, we have two mutually-exclusive scheduling params,
> `schedule_interval` and `timetable`. As it stands now, AIP-48 will be
> adding a *third* such par
As of airflow 2.3, we have two mutually-exclusive scheduling params,
`schedule_interval` and `timetable`. As it stands now, AIP-48 will be
adding a *third* such param, `schedule_on`.
I think it would probably be best to consolidate these into one single
scheduling param. What do you think? What
25 matches
Mail list logo
