potiuk commented on code in PR #36160:
URL: https://github.com/apache/airflow/pull/36160#discussion_r1422327364
##########
dev/README_RELEASE_PROVIDER_PACKAGES.md:
##########
@@ -164,16 +164,6 @@ Details about maintaining the SEMVER version are going to
be discussed and imple
breeze release-management prepare-provider-documentation [packages]
```
-NOTE! When you want to release a provider marked for removal (needed in order
to prepare last release of the
-provider), documentation for the provider will not be prepared when you
prepare documentation for
-all providers - you have to specifically use the provider name in a separate
command.
-For example to prepare documentation for `removed.provider` provider marked
for removal you need to run
-separately this command:
-
-```shell script
-breeze release-management prepare-provider-documentation removed.provider
Review Comment:
> The removed.provider appears in more places on the guide build docs steps
and others how can we guarantee not to miss it?
Ah. Let me check it.
> I think (if it's easier) maybe to leave the current process as is but have
the `breeze release-management prepare-provider-documentation` to output at the
end message about removed providers that were not prepared.. That way If I
missed something I can know and run it specifically for them
We could do it this way too, but I think it's generally fine to simply treat
"removed" providers during the release process as "regular" ones. In many ways
they are regular - we are preparing and releasing them in the same way as any
other providers, including generating and publishing documentation. There is no
difference (I have not realized it before - but from the release process point
of view they are same as any other provider.
So I **think** it's ok to make them just part of regular process.
The thing is that it is really temporary - only for the period between
scheduling for removal and only for the "release" process. - those providers
will be actually removed right after they are released.
I think it will be better to just have them treated as regular ones in this
case - if you think it's a good idea after the explanation.
--
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]
