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 <https://airflow.apache.org/docs/apache-airflow/2.7.0/release_notes.html#the-trigger-ui-form-is-skipped-in-web-ui-if-no-parameters-are-defined-in-a-dag-33351> is more or less what I'm referring to. While this was a breaking change, users were given the option to "roll back".
On Thu, Aug 31, 2023 at 12:14 AM Amogh Desai <amoghdesai....@gmail.com> wrote: > 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 versioning that indicates compatibility, > users might hesitate to upgrade due to concerns about potential > breaking changes. This could lead to fragmentation, where different > users are using different versions of the software, making support and > maintenance more challenging. > > - Release Communication: Semantic versioning helps communicate the > impact of a release to users, maintainers, and contributors. Without > clear versioning, understanding the significance of a release becomes > more difficult. > > > Thanks & Regards, > Amogh Desai > > > On Thu, Aug 31, 2023 at 3:56 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > > > > 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 point. Yes. I believe so. I was never a big fan > of > > introducing breaking changes in providers to make maintainers' lives a > bit > > easier. While I was a big fan of doing it when we had a very good reason. > > > > I think we have too many breaking changes in providers now. And we do it > > because we "can" - we mostly only consider maintainer's lives easier > > currently. But I think when those regulations are in place we will have > to > > make a much more deliberate judgment on when we make a major release > > in providers and take on a deliberate decision "is it worth doing it, > > knowing that we will have to deliver patches for previous major > versions". > > This will be something that the regulations might make us think about > when > > making a decision "should we break?". And when we do - we should be > > prepared to cherry-pick security fixes to those old versions. We > currently > > can have a process for it - and it is off-loaded mainly to stakeholders. > > > https://github.com/apache/airflow/blob/main/PROVIDERS.rst#mixed-governance-model > > - where we mainly take care about releasing cherry-picked code. > > > > I believe the overwhelming majority of those "breaking" releases that we > > really needed, were in providers where there is an active stakeholder > > already cooperating with us. I have - honestly quite an expectation that > > this will stay like that. In the proposed regulations, the stakeholders > are > > (much more than the OSS foundations) responsible for security of the > > software they provide to their users and they will have incentive to fix > > and provide fixes also for past releases of those integration. And I > think > > we can work out a collaborative model on that - very close to the "mixed > > governance" we already have. And in other cases where we have no active > > stakeholders, we might simply refrain from making breaking changes if not > > absolutely needed. > > > > That would be my approach to the elephant. > > > > J, > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > For additional commands, e-mail: dev-h...@airflow.apache.org > >
