> This doesn't sound right to me.
I think it could be right if we do two things:
1) ask the user at migration time "Are you using this feature? Are you ok
with changing the default to switch it off" (we can also revert that
question and ask them "are you ok with switching old default to new
>
> would definitely be in favour of that approach and using it more
> liberally. I think SemVer does not say anything about this case - "the
> software still supports it but you need to flip a flg" sounds like a nice
> way of introducing behavioural changes without breaking changes.
This
> What about more frequently using news fragments + using configuration
settings as a way to introduce breaking changes that users can revert?
I would definitely be in favour of that approach and using it more
liberally. I think SemVer does not say anything about this case - "the
software still
What about more frequently using news fragments + using configuration
settings as a way to introduce breaking changes that users can revert?
Disabling
"trigger dag with config" without Params by default
Very good discussions going on here.
Semver has been a point of concern for us too in our internal product.
Some ideas emerging out of this could help me there. Thanks, Jarek and
Niko.
There are two points I'd like to stress on to say why semver is that important:
- Compatibility: Without
> Now, one elephant in the room - the 5 year security patches thing Jarek
brought up. I freely admit I haven't tracked this at all, so please correct
me if I'm wrong. If that ends up panning out though, I think we will have
to reassess our strategy with providers too.
Just to answer the last
Shubham touched on it a bit, but I want to bring providers into the fold a
bit as well. I don't think there is enough focus on provider versions. Us
maintainers of Airflow have greatly benefited from being able to have
breaking provider changes, but I always get the impression the average user
Or we could even have a policy that... just globally, by default, new
features in core (and yes this may be not well defined) are automatically
beta for 2 minor releases (whether they are hidden behind experimental flag
or not).
Other followup thought...
And I could be reaching a bit here...
* Very much agree on using "experimental" more. So far we used it mostly as
things where maintainers were somehow split on "is it good or not" - but
having "experimental" flag by "default" for new big feature for 2 minor
releases or so would be pretty good approach
* Also I agree 'backwards
I should say... the cost is not quite "hindering adoption of the
feature"... because it doesn't really matter to the heath of the project if
users are using every single feature. Where the rubber meets the road here
is probably more accurately understood as, perhaps the frustration a user
might
I agree with Jarek and Niko regarding the importance of SemVer for Airflow
and how it aids in maintaining user trust.
However, I am not a fan of the strict application of SemVer, especially in
how we consider a small change in default values as a breaking change.
IMHO, an alternative solution for
Just to add to my points about responding to our user.
This is - of course - anecdotal - but this is a transcript from today's
Slack conversation I got with one of the users, and this is not the first
conversation I had of this kind:
It's only because of Strict Semver policies I can very
Same, I was very tempted by this at first but Jarek and Niko changed my
mind. I think sticking to semver will be more beneficial in the long run.
On Wed 30 Aug 2023 at 04:09, Mehta, Shubham
wrote:
> I couldn’t agree more with Jarek and Niko's perspective on the importance
> of maintaining
I couldn’t agree more with Jarek and Niko's perspective on the importance of
maintaining SemVer for Apache Airflow.
I've had conversations with dozens of customers, and it was a lot easier to
convince them to upgrade for a more stable and secure Airflow environment. The
key selling point was
).
Cheers,
Niko
From: Daniel Standish
Sent: Sunday, August 27, 2023 9:04:51 AM
To: dev@airflow.apache.org
Subject: RE: [EXTERNAL] [DISCUSS] move from semver to a more "rolling" release
cycle for core
CAUTION: This email originated fr
>
> Since I was called :)
As though you needed to be called to chime in ;)
Yeah and the other thing that your comments made me think of was... how it
could make provider management more challenging. Because though currently
we have min_airflow_version set in providers and we can use that to
And to clarify, when I talk about putting pressure on major releases, what
I mean is that there's this notion that a major release has to have some
very special or big feature change. One reason offered is marketing.
Major release is an opportunity to market airflow, so take advantage of
that.
For whatever reason, I was reminded recently of snowflake's "behavior
change" policy
See here: https://docs.snowflake.com/en/release-notes/behavior-change-policy
I think semver is problematic for core because basically you cannot
implement behavior changes until the "mythical" major release.
18 matches
Mail list logo
