WIP Release infra stuff

[snazy]

Introduce a couple of shell scripts to automate the release process. Some docs are included under releases/README.md.

Generally, releases at the ASF follow the following workflow:

1. Draft a release
2. Start a VOTE on the dev mailing list
3. If the VOTE fails, the release has failed - "go to step 1"
4. If the VOTE passes, publish the release

The above process is, without release branches, reflected in the scripts:

1. releases/bin/draft-release.sh --major <major-version-number> --minor <minor-version-number> --commit <Git-commit-ID>
2. if the vote passes: releases/bin/publish-release.sh --major <major-version-number> --minor <minor-version-number>
3. if the vote fails, just run draft-release.sh again

The change includes scripts to handle version branches, however, using those is not required for the two release scripts above.

It's important to know that the scripts handle changes to the version.txt file and that a specific syntax for Git tags is expected, which is required to automatically use/generate RC and final versions, including the artifact publishing via Sonatype.

[jbonofre]

Thanks for that !

I will double check as I identified several issues during the first RC.

[jbonofre]

By the way, it would be great to sync: as said on the mailing list (in the release thread), I'm working on similar release script/check. I will sync with your PR.

[snazy]

By the way, it would be great to sync:

We did, I mentioned this in one of the calls, quite some time ago though ;)

[jbonofre]

By the way, it would be great to sync:

We did, I mentioned this in one of the calls, quite some time ago though ;)

@snazy you know I'm getting old, I didn't remember 😄

[snazy]

Some examples that work now. When you try the following commands without the --dry-run flag, make sure to let your local versioned-docs branch use a different upstream repository than apache/polaris.

• releases/bin/draft-release.sh --major 0 --minor 1
  • Using the version 0.1.0-incubating-rc1
  • Creates release notes from relevant Git commits
  • When run in GH actions: Publish to the maven artifacts to Apache's Sonatype (published to the local maven repo otherwise) & generates source tarball
  • Uploads the source tarball to the ASF SVN (only when run in GH actions, otherwise to a local "replacement" SVN repo)
  • Creates the apache-polaris-0.1.0-rc1 tag using a new commit from the "base commit" that has the changes purely for that release (release notes, staging repo information).
  • Pushes the changes to the upstream git repository
  • Prints "VOTE" vote email subject and body proposal
  • Pushes the Git tag
• Calling releases/bin/draft-release.sh --major 0 --minor 1 (same major/minor version) again works similarly, but
  • Uses the version 0.1.0-incubating-rc2
  • Creates the apache-polaris-0.1.0-rc2 tag,
  • Replaces the RC1 source tarball with the one for RC2
• releases/bin/publish-release.sh --major 0 --minor 1
  • Adds the apache-polairs-0.1.0 tag (to the same commit as the latest RC tag apache-polaris-0.1.0-rc2)
  • Adds the apache-polaris-0.1.0-incubating source tarball to the releases-SVN (local SVN, if not run via GH actions)
  • Removes all source tarballs for 0.1.0 from the dev-SVN
  • When run in GH actions: release the staging Sonatype repository
  • Pushes the new Git tag
  • Prints "ANNOUNCE" email subject and body proposa
  • Generates (copies) + adds the 0.1.0 version to the versioned-docs branch
• Running releases/bin/publish-release.sh --major 0 --minor 1 again results in an error message (no RC for the "latest" 0.1.x)
• Calling releases/bin/draft-release.sh --major 0 --minor 1
  • Would work like above, but for 0.1.1 (the next patch release)

This change is not yet ready, but it looks very promising.