I think we can come up with automation that when provider is marked as not ready it will automaticly set .devX when we bulk release providers. That way there cant be any mistakes.
בתאריך יום ה׳, 3 באוק׳ 2024, 16:48, מאת Ephraim Anierobi < [email protected]>: > +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 <[email protected]> > wrote: > > > Thanks Jarek , I am updating the pr now. > > > > Regards, > > Pavan > > > > On Thu, Oct 3, 2024 at 8:26 AM Jarek Potiuk <[email protected]> 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 <[email protected]> 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. > > > > > > > > > > > > > > > > > >
