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
