Support some form of pre-releases (SNAPSHOTs? arbitrary non-SNAPSHOT releases from PR branches?)

[rtyley]

I'm also wondering if I can make releasing arbitrary non-SNAPShot releases from PR branches possible, in which case SNAPSHOTs may not be necessary?

SNAPSHOT releases may be hard to implement

Getting the workflow to offer SNAPSHOT releases may be problematic, as the workflow currently uses 'bundle uploads' for two reasons:

• 'bundle uploads' are much faster, as all artifacts are uploaded in a single HTTP request, rather than 1 request per file
• sbt-sonatype supports bundle uploads by first extracting all required files to a local 'staging' folder, then uploading everything in that folder. This is actually a useful security isolation point for our workflow, because the files can be generated in a 'untrusted' 🎊 workflow job, and then handed on in isolation to a 'secure' 🔒 workflow job to do the bundle upload.

Apparently, Sonatype does not support bundle uploads on its Snapshots repository:

If isSnapshot.value is true (e.g., if the version name contains -SNAPSHOT), publishSigned task will upload files to the Sonatype Snapshots repository without using the local bundle folder.

...so supporting SNAPSHOTs may complicate the workflow.

Detecting the default branch

play-secret-rotation % gh repo view --json defaultBranchRef --jq .defaultBranchRef.name
main

Detecting the current branch

GITHUB_REF_NAME

${{ github.ref_name }}

What should our preview version-suffix look like?

https://semver.org/#spec-item-9 says:

9. A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.--.

10. Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD.

How can we prevent tooling from thinking our preview releases are stable releases?

If we're not using the -SNAPSHOT suffix, there's a risk that tooling will assume that our preview releases are stable releases, and attempt to auto-upgrade to them.

• IntelliJ automatically suggests dependency upgrades - it uses PackageVersionNormalizer (tests) with specific stability tokens that include 'preview'
• Scala Steward raises dependency upgrade PRs - it uses isPreRelease which recognises Hash (6+ or 8 hex chars) & specific Alpha components that include 'preview'. See also Only consider versions with pre-release identifiers as pre-releases scala-steward-org/scala-steward#1033, Treat versions with hashes as pre-releases scala-steward-org/scala-steward#1549 etc
• Scaladex uses PreRelease.scala Dont show invalid sbt and scalajs versions scalacenter/scaladex#614

Consequently, to be certain of being recognised as a pre-release, it seems wise to include these components in the version number:

• 'PREVIEW'
• a commit hash

An example version might look like this:

2.6.4-PREVIEW.add-feature.2023-02-03T1201.afafafaf

[rtyley]

Done with #19 !