Bump apache-airflow-providers-common-sql>=1.27.5 for Snowflake

[eladkal]

For the fix in #53837 to work properly we need to make sure it uses apache-airflow-providers-common-sql version with the fix as the combination of fix in the two providers is what resolving the problem

[potiuk]

This will only work when the dependent provider version is bumped in the same PR or after it has been bumped. You might want to possibly merge it into #54193 or merge it (and update release notes) after #54193 is merged. Same story as before -> you cannot depend on something that locally has previous version

[eladkal]

This will only work when the dependent provider version is bumped in the same PR or after it has been bumped. You might want to possibly merge it into #54193 or merge it (and update release notes) after #54193 is merged. Same story as before -> you cannot depend on something that locally has previous version

Right. Thought about that but didn't want to hide this in the 200 file changes. Will do this as part of the release process

[eladkal]

Closing.
Added it in bf68f4f as part of #54193

[potiuk]

I was thinking of ways we could handle it in the future after our last discussion about newsfragments. I think (again) newsfragments is not a good solution - because they basically do not solve THIS problem you see now.

But what we could do rather "easily" is to have a way to mark (for example with a commant in pyproject.toml) that when preparing documentation for release we could automatically bump it to the next version after the release is prepared. For example:

   "apache-airlflow-provider-common-sql>1.27.4",   # bump this to next version when releasing because of  #NUM_PR

If we keep it in the code between releases, that could avoid having to bump version earlier, and the "prepare-documentation" step could be extended by an extra step at the end. Something like:

The snowflake provider is marked to use new version of commons-sql (bumped to 1.27.5). Current version is 1.27.4. Do you want to bump the dependency version to 1.27.5 ?

That could make it easier - you would not have to remember that we need to bump it. But it would require some explanation to contributors and care at the review time to make sure such comment is added.

[eladkal]

our last discussion about newsfragments

But this is not a change that would have require a newsfragment. As I mentioned before, I don't want to change the current changelog generation process. It works well. My thoughts were about adding a missing component to avoid the cases where PR authors need to manually add comment blocks to the change log.

[potiuk]

But this is not a change that would have require a newsfragment. As I mentioned before, I don't want to change the current changelog generation process. It works well. My thoughts were about adding a missing component to avoid the cases where PR authors need to manually add comment blocks to the change log.

But we want the PR authors to add comments to Changelog when there are cases that require "newsfragment" type of information - simply there is absolutely no reason to use newsfragments for that. The only reason we need newsfragments for it in airflow is that we cherry-pick commits and we never know which of the changelog entries from newsfragment should land in the vX-Y-test branch - because that is decided at cherry-picking change.

In case of providers - we always release from main. And this means that it always contains "all" entries that should find it's way to changelog - including those that individual authors want to add - additionally to commit message. And we are already doing it - when there is a change that requires additional instructions, migrations and warnings, PR authors should add this to changelog and this causes absolutely no problems - because that change lands on top of the changelog and it's super-easy to merge it with the changes in changelog generated during "prepare-providers-documentation". This is "no problem"

What IS a problem (like evidenced in this case) is if the authors in the PR ALSO update the version of provider - in both - pyproject.toml and in provider.yaml. THIS is what causes the current path of "prepare-provider-documentation" to not follow the classification that you do. Not the changelog entry added by PR author - but increasing the version number by the author.

My proposal is then to solve the actual problem - i.e. even if we need to bump the version of provider A (because ANOTHER provider B depends on features that will be released in the future version of provider A) - we can defer that bump to the moment release manager prepares documentation for the next wave. This is what I proposed. Instead of actually "bumping" the version by the author, the author will leave the comment that will semi-automatically (guided by the release manger) make sure that whatever new version of provider A will be bumped during document preparation - provider B will get `provider A >= NEW VERSION of Provider A).

This should actually solve the problem - and newsfragments are not even close to solving that problem that we had. It will cause root reason why we have this - effectiveley - edge case now that sometimes when you generate provider, documentation and the version of the provider has been bumped before - you have to manually classify the changes.

Simply - when this proposal is implemented, we will NEVER have the case that PR author bumps version of a provider. Like NEVER. This will be strictly forbidden. Only release manager will be able to bump the version - when running "prepare-providers-documentation" . The PR author will only leave a note "Hey release manager when you bump this provider , the other provider should have >= this new version" - and we can automate that part.