Allow setting major version

[danielrbradley]

Fixes #13

The inference of the major version can currently lead to some unexpected results. Add an option to pass in the expected major version to this action to ensure the major version is the desired value.

The only exception where the major version is ignored is when pushing tags. Tags are expected to be the exact version to publish, so we don't do any kind of inferrence there.

[thomas11]

The code looks correct, but the explicit major version silently overriding the three implicit methods seems like a potential source of hard-to-debug issues. For instance, when a new vN+1 branch is started and the user forgets to increment major-version, won't it silently release vN? Would it be clearer for the user to decide on one approach?

[danielrbradley]

The implicit part is still needed to generate reasonable version numbers i.e. if the last release was 2.3.0 then the branch build should be 2.4.0-[hash] and not 2.0.0-[hash].

For real releases this has no impact as tags are taken as-is and there's no implicit behaviour. This only affects automated pre-releases.

[thomas11]

The implicit part is still needed to generate reasonable version numbers i.e. if the last release was 2.3.0 then the branch build should be 2.4.0-[hash] and not 2.0.0-[hash].

My suggestion would be to run the implicit part to determine the correct version, then check if the major versions match (if major-version is specified), and fail if they don't.

[danielrbradley]

I think we could print a warning, but an error would be very disruptive as the issue is that the inferred major version is often sometimes wrong, so we want to explicitly fix the major version in place and disable the major version inference entirely.

[thomas11]

LGTM pending some logging of how the version was determined, and if there was a discrepancy between explicit and implicit.

[pulumi-bot]

This PR has been shipped in release v1.6.0.