Hi, All and Xiao (as a next release manager). In any case, can the release manager include the information about the used release script as a part of VOTE email officially?
That information will be very helpful to reproduce Spark build (in the downstream environment) Currently, it's not clearly which release script is used because the master branch is also changed time to time during multiple RCs. We only guess some githash based on the RC start time. Bests, Dongjoon. On Mon, Apr 29, 2019 at 7:17 PM Wenchen Fan <cloud0...@gmail.com> wrote: > > it could just be fixed in master rather than back-port and re-roll the > RC > > I don't think the release script is part of the released product. That > said, we can just fix the release script in branch 2.4 without creating a > new RC. We can even create a new repo for the release script, like > spark-website, to make it clearer. > > On Tue, Apr 30, 2019 at 7:22 AM Sean Owen <sro...@gmail.com> wrote: > >> I think this is a reasonable idea; I know @vanzin had suggested it was >> simpler to use the latest in case a bug was found in the release script and >> then it could just be fixed in master rather than back-port and re-roll the >> RC. That said I think we did / had to already drop the ability to build <= >> 2.3 from the master release script already. >> >> On Sun, Apr 28, 2019 at 9:25 PM Wenchen Fan <cloud0...@gmail.com> wrote: >> >>> > ... by using the release script of Spark 2.4 branch >>> >>> Shall we keep it as a policy? Previously we used the release script from >>> the master branch to do the release work for all Spark versions, now I feel >>> it's simpler and less error-prone to let the release script only handle one >>> branch. We don't keep many branches as active at the same time, so the >>> maintenance overhead for the release script should be OK. >>> >>>> >>>>
