Breaking changes in "main" branch on 5 April

[maxim-lobanov]

Hello everyone!

Recently, we have published actions/setup-java@v2-preview with support of Zulu and Adopt distributions.
We are going to make the stable release and push v2-preview changes on main on 5 April 2021.

It won't affect customers who pin on specific tag of action like actions/setup-java@v1 or actions/setup-java@1.1.0 but it will break customers who pin their workflows to actions/setup-java@main. Workflows will be broken because V2 has required input distribution. According to GitHub Actions documentation, it is not recommended to pin workflow to main branch.

To mitigate the issue, we suggest pinning your workflow to actions/setup-java@v1.

[giltene]

The proposed timeframe (for pushing breaking changes to main) is way too early IMO, unless one intends to change behavior from this point forward, and to keep adding breaking changes to the “main” branch every few weeks from now on, prevention “main” from stabilizing in a non-breaking-change manner.

Given the breaking nature of multiple new behaviors proposed in the current v2 preview, and the lack (this far) of a publicly accessible description of the actual set of v2 behavior changes intended, significantly more user feedback (as opposed to action developer feedback) on the v2 preview version is needed, with time to react to that feedback needed and potential break-the-breaking-changes needed as well.

Some proposed behavioral changes that I am aware of so far include a complete change to the means by which distro binaries are pulled (cdn scraping to api), newly introduced (and very significant) update lag times, new required properties, and new properties with defaults that change behavior quite significantly (and sometimes subtly but materially) from what a v1.x setup-java does today. The dust has not settled on most of those, and user feedback on their impact is still pending. The preview v2-branch is a fine place to continue gathering that feedback and potentially adjusting choices in ways that would “break” v2-preview to v2-preview compatibility. It would be preferable IMO for v2 preview to reach an empirically stable level, where no breaking changes have been done within it for a while, before merging into the “main” branch.

This, obviously, goes doubly so for v2 itself. Since the next opportunity to create any breaking changes (that will break with those that will actually get included in the first non-preview v2) will be a long time down the road, in a v3,, it would be advisable to avoid rushing in a set of breaking changes without allowing the v2 preview to bake in actual user experience, feedback and refinement for a sufficient amount of time to gauge stability.

[scordio]

Another point related to the breaking change is that all the PRs raised by dependabot (e.g., assertj/doc#96 and assertj/assertj-guava#69) now require manual action, which is unpleasant.

[maxim-lobanov]

Closing the issue since changes were merged to main.
As for the dependabot, yes, unfortunately, it can't fix such breaking changes and just bump version in YAML file that causes some noise.

[jglick]

Unfortunately as seen in for example jenkinsci/azure-artifact-manager-plugin#14 a bump from v1 to v2 shows a list of commits but there is no clear indication that this is incompatible (beyond guessing based on the number scheme) or what you need to do to fix it; the text in https://github.com/actions/setup-java/releases/tag/v2.0.0 is not displayed.

(Oh and the release notes neglect to mention that 1.8 is no longer a legal version and you must switch to 8. https://github.com/actions/setup-java/blob/v2.0.0/docs/switching-to-v2.md#dropping-legacy-java-version-syntax-1x notes this but you would have to click through to it.)