+1 to release the pre-release providers manually, outside the regular release process. If we decide to add it to the regular release process, my concern is accidentally pushing a pre-release of an already-released provider. If that can be prevented, then I'm okay with adding it to the regular release process.
On Thu, 3 Oct 2024 at 08:32, Pavankumar Gopidesu <gopidesupa...@gmail.com> wrote: > Thanks Jarek , I am updating the pr now. > > Regards, > Pavan > > On Thu, Oct 3, 2024 at 8:26 AM Jarek Potiuk <ja...@potiuk.com> wrote: > > > I provisionally generated and uploaded the .dev0 package > > https://pypi.org/project/apache-airflow-providers-standard/1.0.0.dev0/ > > from > > latest main - and we shall see if everything works as expected (see > > https://github.com/apache/airflow/pull/42252#discussion_r1785222999) > > > > On Wed, Oct 2, 2024 at 1:37 PM Jarek Potiuk <ja...@potiuk.com> wrote: > > > > > > > >> Mainly for the case of standard provider and the integration > > >> chicken-and-egg problem to un-block the work. > > >> > > > > > > > > > Yes - for example this: > > > https://github.com/apache/airflow/pull/42654#issuecomment-2387999058 > > that > > > resulted in some conditional "skip-if" that should not be needed when > we > > > release final version of the provider - having a .dev* version of > > provider > > > in PyPI which we could release semi-frequently with new code should > solve > > > the problem entirely. > > > > > > > > > > > >> For edge.. no pressure, some PRs are waiting (still unfortunately). > As I > > >> am biased for edge, I'd first propose for standard as PR #42676 > > >> > > > > > > Agree. Edge will not be pre-installed and there should be no dependency > > on > > > it in the airflow CI, or other providers that might cause such > failures. > > > > > > > > > > > >
