[
https://issues.apache.org/jira/browse/FLINK-33301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779122#comment-17779122
]
Matthias Pohl edited comment on FLINK-33301 at 10/24/23 2:52 PM:
-----------------------------------------------------------------
{quote}
Yes, using pom to control the versions centrally is a good idea. But the
current Flink release is not pure maven based, it contains many scripts beyond
Maven. If someone like me has wrong versions of Java or Maven, it can only be
failed at the time when maven -Prelease is called.
{quote}
That is why we have the script. So that you don't have to call {{mvn
-Prelease}} on your own.
{quote}
During Flink 1.18 release I ran the release process 4 times and I have other
works in between. Since Flink is an open source project, I guess what I was
facing is very common, release managers will have other works in parallel. Java
and Maven versions will be switched back and forth depending on which project
the release manager is working on. Each time, when I switched back to Flink
release, I would not always call mvn -Prelease, because I already did the
preparation. I just jumped into the "Build a release candidate" section. All
scripts described on the wiki page will be executed. And the fact is that I
created my own protocol/program to execute the release in order to move faster
without read the long content. At that time, my only focus was those scripts. I
had the version issues twice more in addition to the one detected by rc2. As a
release manager, I am keen to have the check at script level, because it is the
entry point of my work. I might have my own script on top of the official
scripts to save even more time. Like I did with the PR to have the following
error messages(as example) at very beginning with any script I might call:
{quote}
Just for the record: the only value you're adding is that the error is raised
when calling {{tools/releasing/create_source_release.sh}}. The other two script
do print the error already (because they call Maven's enforcement plugin).
Additionally, you're introducing a helper script that can be used if you're not
familiar with the Maven features for calling the version enforcement correctly.
In contrast to that, you're adding one additional artifact where we have to
maintain the Maven and Java version. You could adapt your script in a way that
it uses the Maven command, I shared in my comment above. This way, we don't
introduce new code locations with the version being hard-coded but rely on the
Maven configuration. That keeps maintainability at the current level.
You could even grep for the relevant output if you're concerned about the
verbose ERROR output: {{mvn -q -Prelease -pl flink-annotations validate | grep
-v ERROR}}. WDYT?
was (Author: mapohl):
{quote}
Yes, using pom to control the versions centrally is a good idea. But the
current Flink release is not pure maven based, it contains many scripts beyond
Maven. If someone like me has wrong versions of Java or Maven, it can only be
failed at the time when maven -Prelease is called.
{quote}
That is why we have the script. So that you don't have to call {{mvn
-Prelease}} on your own.
{quote}
During Flink 1.18 release I ran the release process 4 times and I have other
works in between. Since Flink is an open source project, I guess what I was
facing is very common, release managers will have other works in parallel. Java
and Maven versions will be switched back and forth depending on which project
the release manager is working on. Each time, when I switched back to Flink
release, I would not always call mvn -Prelease, because I already did the
preparation. I just jumped into the "Build a release candidate" section. All
scripts described on the wiki page will be executed. And the fact is that I
created my own protocol/program to execute the release in order to move faster
without read the long content. At that time, my only focus was those scripts. I
had the version issues twice more in addition to the one detected by rc2. As a
release manager, I am keen to have the check at script level, because it is the
entry point of my work. I might have my own script on top of the official
scripts to save even more time. Like I did with the PR to have the following
error messages(as example) at very beginning with any script I might call:
{quote}
Just for the record: the only value you're adding is that the error is raised
when calling {{tools/releasing/create_source_release.sh}}. The other two script
do print the error already (because the call Maven's enforcement plugin).
Additionally, you're introducing a helper script that can be used if you're not
familiar with the Maven features for calling the version enforcement correctly.
In contrast to that, you're adding one additional artifact where we have to
maintain the Maven and Java version. You could adapt your script in a way that
it uses the Maven command, I shared in my comment above. This way, we don't
introduce new code locations with the version being hard-coded but rely on the
Maven configuration. That keeps maintainability at the current level.
You could even grep for the relevant output if you're concerned about the
verbose ERROR output: {{mvn -q -Prelease -pl flink-annotations validate | grep
-v ERROR}}. WDYT?
> Add Java and Maven version checks in the bash script of Flink release process
> -----------------------------------------------------------------------------
>
> Key: FLINK-33301
> URL: https://issues.apache.org/jira/browse/FLINK-33301
> Project: Flink
> Issue Type: Bug
> Components: Release System
> Affects Versions: 1.18.0, 1.19.0
> Reporter: Jing Ge
> Assignee: Jing Ge
> Priority: Minor
> Labels: pull-request-available
>
> During the release, Flink requires specific version of Java and Maven[1]. It
> makes sense to check those versions at the very beginning of some bash
> scripts to let it fail fast and therefore improve the efficiency.
>
> [1][https://lists.apache.org/thread/fbdl2w6wjmwk55y94ml91bpnhmh4rnm0|https://lists.apache.org/thread/fbdl2w6wjmwk55y94ml91bpnhmh4rnm0]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
