Skip to content

mrun 0.2.0

Choose a tag to compare

@github-actions github-actions released this 14 Sep 04:42
f303cb4

Added

  • Install and upgrade with one line of PowerShell (9c968fa)

    irm https://raw.githubusercontent.com/blendonl/mrun/main/install.ps1 | iex
    downloads the latest release into %LOCALAPPDATA%\Programs\mrun and adds
    that folder to the user PATH, so mrun works in any new terminal with no
    manual steps.

    • Running it again upgrades in place. A copy running from the install
      folder is quit first, so its exe is not locked, and started again with
      --daemon afterwards. Copies running from anywhere else are left alone.
    • The PATH entry is only added once. The value stays REG_EXPAND_SZ with its
      %VARIABLE% entries unexpanded, and the change is broadcast so Explorer
      and newly opened terminals see it.
    • -Version pins a release and -InstallDir picks another folder.

Changed

  • Stop carrying mshell's name (a211dfe)

    mrun is a standalone launcher and works with or without mshell.

    • Log to %LOCALAPPDATA%\mrun\mrun.log instead of mshell's directory.
    • The version resource, manifest identity and usage line name mrun, not mshell.
    • The shipped config drops its "Reload mshell" entry, which failed anywhere mshell is not installed.
    • README and MANUAL-TESTS no longer describe mshell's launcher handoff, which mshell has removed; under mshell, mrun is bound with mshell.exec like any other program. The link to mshell stays.

Other

  • ci: Publish a release when main carries an untagged version (66c28f8)

    After a green build on main, compare the Makefile's VERSION against the
    tags on origin. If v$VERSION does not exist yet, tag the commit and publish
    a GitHub release with the zip the build job just assembled, using that
    version's CHANGELOG section as the notes. A version with no changelog
    section fails the job instead of releasing with empty notes.

  • build: Work out the next version and changelog section from commits (5e754b5)

    make bump reads the Conventional Commits since the latest vX.Y.Z tag,
    picks the next version and writes it to VERSION in the Makefile, with a
    matching CHANGELOG.md section grouped into Breaking, Added, Fixed, Changed
    and Other. Commit bodies are kept under each entry; trailers are dropped.

    Before 1.0, feat, fix and breaking changes bump the minor version; after,
    breaking bumps the major, feat the minor and fix the patch. Anything else
    bumps the patch.

    Running it again replaces the pending section rather than stacking a new
    one, and chore(release) commits are left out, so it can run on every push
    to a branch.

  • ci: Commit the version bump to pull requests into main (975cafc)

    When a pull request into main is opened or updated, run make bump on its
    branch and push the result as chore(release): vX.Y.Z. Merging it then
    leaves main on an untagged version, which the release job tags and
    publishes. Nothing is ever committed to main by CI.

    Pull requests from forks are skipped, since the workflow token cannot push
    to them.

  • docs: Describe how releases are cut (0e9aee2)

    Point Install at the Releases page, and explain in a new Releases section
    how the version is chosen, what the bot commit on a pull request is, and
    how to avoid it with make bump.