potiuk commented on code in PR #28651: URL: https://github.com/apache/airflow/pull/28651#discussion_r1059553691
########## airflow/providers/imap/CHANGELOG.rst: ########## @@ -24,6 +24,16 @@ Changelog --------- +3.1.1 +..... + +Misc +~~~~ + * ``[misc] Get rid of 'pass' statement in conditions (#27775)`` Review Comment: I personally would not remove it ferom the release. I usually released all of the "actual" changes. If the release did not make any code modifications it could be marked as "doc only change" - which means that documentation would be updated but the package itself was not released. With such "small" code changes, it's always on the fence and I think this is just a question of "do we want to mess arround with the same change next time when we release" or "should we release now and forget about it". From the release manager point of view - I prefer to release any "potentially breaking changes" as soon as they are merged. Even if they are just "pass" statement removals. Because even smallest code changes might contain completely non-obvious bugs. The mantra "release early, release often" is very much applicable here. What if you keep on doing it (not releasing this change), then not releasing next similar "innocent" refactor next month for the same provider, and so on. And then releasing 5 such changes in 5 months when there is a bigger change and finding out that one of those "innocent" changes broke something. But in 5 months you not only have to spend time finding out which one broke it but also the person who made the change will completely forgot on why and how or might be not available any more. By releasing now (and adding the "Status" Issue - you add an extra "peer" pressure on the user who implemented it. It is fresh. The user still remembers it. And more often than not they will actually install the new provider RC and do some testing with it. And even if not, if someone else finds a bug in the newly released provider, you know immediately whom to ask for help. Do you think it will happen if you release 5 similar changes are released together in 5 months? I think it's far, far, far less likely. I think not relasing now is optimizing the wront thing. By not realising we seem to optimize "number of releases in PyPI". Which is wrong optimization goal IMHO. There is virtually no overhead for maintainers nor for users to release it - because releases are all automated, and MOST users will just get the bundle together with new version of Airflow. And those users who actually care and install new providers when they are relased will actually appreciate if there are many smaller upgrades rather than than one bigger upgrade because it is easier to go back and investigating problem when it happens. Release (and upgrade) early and often - as counter-intuitive as it is., it gives much better results than release less often. ########## airflow/providers/imap/CHANGELOG.rst: ########## @@ -24,6 +24,16 @@ Changelog --------- +3.1.1 +..... + +Misc +~~~~ + * ``[misc] Get rid of 'pass' statement in conditions (#27775)`` Review Comment: I personally would not remove it feom the release. I usually released all of the "actual" changes. If the release did not make any code modifications it could be marked as "doc only change" - which means that documentation would be updated but the package itself was not released. With such "small" code changes, it's always on the fence and I think this is just a question of "do we want to mess arround with the same change next time when we release" or "should we release now and forget about it". From the release manager point of view - I prefer to release any "potentially breaking changes" as soon as they are merged. Even if they are just "pass" statement removals. Because even smallest code changes might contain completely non-obvious bugs. The mantra "release early, release often" is very much applicable here. What if you keep on doing it (not releasing this change), then not releasing next similar "innocent" refactor next month for the same provider, and so on. And then releasing 5 such changes in 5 months when there is a bigger change and finding out that one of those "innocent" changes broke something. But in 5 months you not only have to spend time finding out which one broke it but also the person who made the change will completely forgot on why and how or might be not available any more. By releasing now (and adding the "Status" Issue - you add an extra "peer" pressure on the user who implemented it. It is fresh. The user still remembers it. And more often than not they will actually install the new provider RC and do some testing with it. And even if not, if someone else finds a bug in the newly released provider, you know immediately whom to ask for help. Do you think it will happen if you release 5 similar changes are released together in 5 months? I think it's far, far, far less likely. I think not relasing now is optimizing the wront thing. By not realising we seem to optimize "number of releases in PyPI". Which is wrong optimization goal IMHO. There is virtually no overhead for maintainers nor for users to release it - because releases are all automated, and MOST users will just get the bundle together with new version of Airflow. And those users who actually care and install new providers when they are relased will actually appreciate if there are many smaller upgrades rather than than one bigger upgrade because it is easier to go back and investigating problem when it happens. Release (and upgrade) early and often - as counter-intuitive as it is., it gives much better results than release less often. -- 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]
