nd generating the snapshots first to
>
> > unblock the
>
> > release process first, and I'll complete the remaining work to automate
>
> > the snapshots
>
> > generating in roughly next week to simplify the future releasing process.
>
> > Do yo
--
Sender:Matthias Pohl
Send Date:Wed Oct 19 14:30:45 2022
Recipients:Flink Dev , Yun Gao
Subject:Re: Re: [DISCUSS] Aligning migration test data generation
I don't think that it's actually a blocker for the current release. It's
more like a nice-to-have. The release managers for 1
releasing process.
> Do you think
> this would work?
> Best,
> Yun Gao
> --
> From:Matthias Pohl
> Send Time:2022 Oct. 18 (Tue.) 18:16
> To:dev
> Subject:Re: Re: [DISCUSS] Aligning migration test data generation
> Thanks for clarifying t
hink
this would work?
Best,
Yun Gao
--
From:Matthias Pohl
Send Time:2022 Oct. 18 (Tue.) 18:16
To:dev
Subject:Re: Re: [DISCUSS] Aligning migration test data generation
Thanks for clarifying things and providing the link to the Jira iss
Thanks for clarifying things and providing the link to the Jira issue. I'd
be curious about the state of your efforts. I'm happy to close my PR if
you're saying that your approach is more reasonable or you're almost done.
But we could also merge both efforts. Either way is fine with me.
Best,
Matt
Hi Matthias,
Very thanks for proposing the issue! Currently when releasing a new version,
it is indeed required to manully generates new test data on the branch to
release
(namely release-1.16) for all the compatibility tests, and then pick the files
back to
the master branch so that the f
I created a draft PR to underline my proposal [1]. The PR doesn't cover all
the relevant tests, yet. I'd like to get feedback from anyone who has done
minor releases in the past (CC'ing Yun Gao since he did this task for Flink
1.15) before proceeding with the tests that are still not migrated (sinc