potiuk commented on PR #54194: URL: https://github.com/apache/airflow/pull/54194#issuecomment-3164173830
> 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-0-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 adde 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. Instaead 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 after 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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
