chore: set up auto for versioning/release management

[hydrosquall]

Motivation

• Unified versioning / release process through the Vega org:
  • less time spent spent to rebuild packages locally/releasing/managing changelogs = more time for new features

Changes

• Replicate the setup in chore: set up auto for versioning/release management  vega-tooltip#566

• Left the documentation + schema publishing steps intact, updated workflows to only trigger those

• Figure out a way to dry-run a test of the documentation publishing step from stable

Discussion topics

• We need to confirm that manually bumping the version via script/bump.sh is not relevant. I didn't want to remove the script until reviewing this with @domoritz . I outline what will happen if we abandon this script on pre-releases, and lean on "auto" to manage version bumps instead.
  • The version in package.json on next will lag the version in stable, leading to PRs like chore: sync prerelease branch version with stable vega-tooltip#575 .
  • This is an unaddressed issue in auto: [question]: Best practices for synchronizing versions in a two-branch prerelease workflow intuit/auto#2047 . I think it's OK as long as we only ever publish documentation from stable. (I think this is a reasonable trade, I don't think we want to be publishing documentation updates before stable releases are made)
  • An alternative if this version drift is a dealbreaker to do away with the 2-branch prerelease process, and instead go with the 1-branch method. This solves the drift issue by eliminating the next branch, at the cost of not being able to do prereleases, and requiring you to manually use the release tag.

Pre-merge checklist for a repo admin

• Create a branch called next from the current head of master https://github.com/vega/vega-lite/tree/next
  • make next the base branch of this PR instead of master
  • make next the base branch for the whole repo
• Create a branch called stable from the latest tag v5.2.0 https://github.com/vega/vega-lite/tree/stable
• Make a tagged release of the latest tag (This is done: https://github.com/vega/vega-lite/releases/tag/v5.2.0 )
• Create tags called skip-release and released in this repo (the first is used to tell auto not to release anything if this PR is released, the second is used to tag PRs that have been released).

[domoritz]

The main tricky thing in Vega-Lite is that we need to update this file whenever we bump the version number. The next tricky thing is to update the website and schema repo as well, which we do in https://github.com/vega/vega-lite/blob/master/.github/workflows/release.yml. We should probably not push schema updates with every pre-release and we should also not update the website until we have a path/minor/major release. I'm happy to answer any questions.

[hydrosquall]

The main tricky thing in Vega-Lite is that we need to update this file whenever we bump the version number

I think we can get away with only updating this on the next -> stable merges, and not modifying this on every prerelease. I haven't decided yet whether we should be trying to make this part of CI, or if it's OK to keep doing this as a manual commit. If we make it part of CI, it could either be a script in the github actions.

If it turns out to be necessary, I can write a custom lifecycle plugin to write the version to that file whenever "auto" has its auto-version command called.

However, I'd like to avoid it if possible since it may be harder for future maintainers to know about/debug.

I wonder if we could make it an option for this file to be built dynamically as part of the site's build step from the version in the package.json so that the updated version doesn't have to be checked into the repo twice. That might be easier to maintain.

We should probably not push schema updates with every pre-release and we should also not update the website until we have a path/minor/major release.

I figured - I thought about it for a while, and decided to leave the release.yml file mostly intact. We'll have the expected behavior if we only have the contents of that file run when there is a merge from next -> stable.

[domoritz]

I'd like to not have to manually update the version file. I like the idea of getting rid of it entirely.

[hydrosquall]

#7972 (comment)

Opened separately as #7983

[hydrosquall]

I'm undoing this branch renaming since it looks like it's a script meant to run in a different repository

https://github.com/vega/schema

[domoritz]

Good catch

[hydrosquall]

This was removed because it's already been released once on the trigger to the push event

[hydrosquall]

I'm no longer able to push commits to this branch due to some kind of Github authentication error. The error message is misleading as I'm not using a PAT to authenticate "git pushes" locally. Closing this PR and reopening as #7984 .

https://a.cl.ly/YEuB0Pnn