Skip to content

RELEASING.md

Latest commit

 

History

History
62 lines (45 loc) · 2.4 KB

RELEASING.md

File metadata and controls

62 lines (45 loc) · 2.4 KB
Raw

How to Tag & Release

Prerequisites

  • Push access to jbangdev/jbang-idea
  • PUBLISH_TOKEN secret configured (JetBrains Marketplace token)

Steps

  1. Update version and changelog in your PR:

    • Set pluginVersion in gradle.properties (e.g. 0.26.0)
    • Add entries under ## [Unreleased] in CHANGELOG.md

  2. Merge the PR to main.

  3. Create a Git tag on main:

    git tag v0.26.0
git push origin v0.26.0

  4. Create a GitHub Release:

    gh release create v0.26.0 --title "v0.26.0" --notes "Release notes here"

    Or use the GitHub UI: Releases → Draft a new release → select the tag → Publish release.

    ⚠️ The release must be published (not draft). The workflow triggers on released or prereleased events only.

  5. The release.yml workflow runs automatically and:

    • Builds the plugin
    • Publishes to JetBrains Marketplace via ./gradlew publishPlugin
    • Uploads the artifact to the GitHub Release
    • Creates a PR that patches the changelog and moves pluginVersion to the next development version (e.g. 0.26.0 → 0.26.1)

  6. Merge that PR right away. Until it is merged, EAP builds of main are versioned below the release you just published (see Early access channel).

Early access channel

Every successful build of main publishes a uniquely versioned build to the eap Marketplace channel. To receive these builds, add this custom plugin repository in IntelliJ IDEA under Settings → Plugins → ⚙ → Manage Plugin Repositories:

https://plugins.jetbrains.com/plugins/eap/18257

Stable releases are also uploaded to eap because custom channels take precedence over the default channel.

EAP builds are versioned <pluginVersion>-eap.<run number>. A pre-release suffix sorts below the plain version (0.26.0-eap.42 < 0.26.0), so pluginVersion on main must always be the next development version, never an already released one. The release workflow takes care of this through its post-release PR; DocumentationTest fails if pluginVersion falls behind the latest release in CHANGELOG.md.

Common Pitfalls

  • Draft releases don't trigger the workflow — you must publish them.
  • Java version — release.yml must match build.yml (currently Java 25).
  • Tag must match a commit on main — the workflow checks out by tag name.