Merge pull request mysql#34 from planetscale/piki/upgrade-docs

More 8.0.23->8.0.30 docs updates

Author: piki

.buildkite/hooks/pre-command

@@ -7,12 +7,9 @@ TODAY=$(date +"%Y%m%d")
 [ -n "$TODAY" ]
 echo "Today = \"${TODAY}\""
 
-git log -25000 --format='%H' | sort > tmp-log
-git show-ref | grep tags/mysql-8 | sort > tmp-tags
-export CONTAINER_SEMVER=$(join tmp-log tmp-tags | sort -t. -n -k3 | tail -1 | cut -d- -f2)
-[ -n "$CONTAINER_SEMVER" ]
-export MYSQL_VERSION="${CONTAINER_SEMVER}"
-export CONTAINER_SEMVER="$CONTAINER_SEMVER.$TODAY"
+. ./MYSQL_VERSION
+MYSQL_VERSION=${MYSQL_VERSION_MAJOR}.${MYSQL_VERSION_MINOR}.${MYSQL_VERSION_PATCH}
+export CONTAINER_SEMVER="$MYSQL_VERSION.$TODAY"
 echo "Semantic version = \"${CONTAINER_SEMVER}\""
 
 export CONTAINER_SHORT_SHA=$(git log -1 --pretty='%h')

_planetscale/docs/README.md

@@ -23,7 +23,7 @@ git co -- README
 rm -r .buildkite/ .dockerignore Dockerfile.* _planetscale/ build.sh docker-compose.yml
 ```
 
-The public repo has one tag per image that we have deployed broadly, with the format `8.0.23-ps1`.  In general, create a commit only when rolling out a new image, which means there will be one tag per commit.  The semver in each tag is the upstream version the build is based on.  The final number (`1` in `ps1`) in each tag is sequential and has no semantic (i.e., compatibility) meaning.
+The public repo has one tag per image that we have deployed broadly, with the format `8.0.30-ps1`.  In general, create a commit only when rolling out a new image, which means there will be one tag per commit.  The semver in each tag is the upstream version the build is based on.  The final number (`1` in `ps1`) in each tag is sequential and has no semantic (i.e., compatibility) meaning.
 
 # Developing
 
@@ -40,7 +40,7 @@ git remote add public [email protected]:planetscale/mysql-server
 git remote add upstream [email protected]:mysql/mysql-server
 ```
 
-Create your development branches and PRs off of `8.0.23`, for now.
+Create your development branches and PRs off of `8.0`.
 
 Create a local branch for public releases:
 
@@ -54,6 +54,8 @@ Every commit to the `8.0` (default) or `8.0.23` branch gets built in CI and push
 
 For more about container management, see [`registry.md`](registry.md).
 
+As new versions are released upstream, wait two months or so to ensure they are stable, and then use a PR merge them into the `8.0` branch of `mysql-server-private`.
+
 # Deployment
 
 Anytime there are changes worth deploying, do an open-source code dump, and update all the release channels.
@@ -68,7 +70,7 @@ git push public 8.0.NN-psN
 
 For the release channels, read the Vitess docs [here](https://coda.io/d/Vitess-Upgrades_dy3xDEfjOx5/Vitess-Upgrades_sui49), and do the MySQL equivalents.  In short, create an api-bb PR to update `MYSQLD_VERSIONS` in [`database_branch.rb`](https://github.com/planetscale/api-bb/blob/main/app/models/database_branch.rb#L174), disable the [`update_mysqld_image_version`](https://admin.planetscale.com/admin/feature-flags/update_mysqld_image_version) feature flag, merge the api-bb PR, and slowly increment the feature flag to 100%.  Normally, new code goes to the `next` channel only.  Repeat the process with `stable` and `oldstable` a day or a week later until all branches are running the desired version of MySQL.
 
-The update process will never downgrade the version of MySQL on a cluster.  An image is newer if its MySQL version (e.g., `8.0.30`) is higher, or if the MySQL version is the same and the build date is higher.  A branch-deployed image (e.g., `8.0.23-20220601-ps-branchname`) is always pinned and does not get replaced by the update process.
+The update process will never downgrade the version of MySQL on a cluster.  An image is newer if its MySQL version (e.g., `8.0.30`) is higher, or if the MySQL version is the same and the build date is higher.  A branch-deployed image (e.g., `8.0.30-20221006-ps-branchname`) is always pinned and does not get replaced by the update process.
 
 # Feature flags