This step introduces the concept of a release train to determine the appropriate release dates and schedules milestones as needed. It uses the following rules:
- If the current SNAPSHOT version is a minor release (patchVersion == 0), checks to see if a GA release exists. If not, a release train is scheduled as follows:
- Finds the next available release train starting month (including this month), either January or July.
- Schedules a release train with M1, M2, M3, RC1 and GA versions on either January/February/March/April/May or July/August/September/October/November
- If the current SNAPSHOT version is a patch release (patchVersion != 0), checks to see if a GA release exists. If not, an individual milestone is scheduled on the next even month whose release day is in the future (can include this month).
- In either case, the release day used to schedule the release is based on the configured weekOfMonth (1-4) and dayOfWeek (1-5), e.g. 3rd Monday of the month (3, 1).
If a milestone already exists, nothing is created. Once created, milestone due dates can be updated manually as desired.
Closes gh-10458
- Add slack integration for error reporting
- Rename from check_windows to build_windows
- Change the build command to match the one in build_jdk_11
- Add build_windows to the needs of deployment and failure check jobs
Issue gh-9727
- There is no need to emit the value of RUN_JOBS to the rest of the
workflow. As a boolean, it is sufficient to ask whether or not the
corresponding output is present at all
- Prerequisites is apparently easy to misspell
Issue gh-9701
Steve Riesenberg
Marcus Da Coregio
Eleftheria Stein
Josh Cummings
Rob Winch
Eleftheria Stein
Ellie Bahadori