Verify that every commit exists on master during release cut

[jridgewell]

This is my attempt to ensure we never have another bad cherry-pick release again (see Failures of versioning recent cherry-picks).

It's extremely important that the version assigned to cherry-pick requests is seen as a continuation of the base release (only the last 3 digits may change). If a new cherry-pick of a beta were to be seen as a brand new release, it would break the monotonic increase we need for npm publishing.

[amp-owners-bot]

Hey @danielrozenberg! These files were changed:

build-system/compile/internal-version.js

[estherkim]

The unexpected amp version occurred because the cherry picked commits were resolving conflicts.

I thought this was a use case that we wanted to support?

[jridgewell]

I thought this was a use case that we wanted to support?

By default, no. If there's something fishy, I'd rather halt than continue. But there's the --skip_commits_verification and --version_override that will allow us to support merge conflicts directly once we know about it.

[jridgewell]

Ping @estherkim

[estherkim]

there's the --skip_commits_verification and --version_override that will allow us to support merge conflicts directly

That should work, as long as we can use that in our release automation process - @danielrozenberg is that possible?

[jridgewell]

That should work, as long as we can use that in our release automation process - @danielrozenberg is that possible?

This is only needed for merge conflicts in CPs, which have to be done manually. All that's needed are documentation changes. The automation process should remain unchanged.

[danielrozenberg]

I wonder if it isn't enough to just have this flag, and discard the other flag. In either case we'll have to change the release automation backend to support this and to add a field to add the overridden version number for these releases, so I wouldn't want to merge this PR before the backend supports it

[estherkim]

Here's another solution that doesn't require version_override or backend changes - #32689

[danielrozenberg]

@estherkim your PR seems fine by me (modulo the comment I left there, which is definitely not a blocker) but I think this current PR could still be relevant

[estherkim]

is this PR a moot poot now?

[CLAassistant]

All committers have signed the CLA.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.