Skip to content

Releases: crmne/native-packages

native-packages 0.6.0

Choose a tag to compare

@crmne crmne released this 14 Sep 15:36
f002ce9

Use one native-packages configuration across Linux and native macOS/Windows release jobs.

  • The reusable Linux workflow accepts a targets input and passes the same selection to build and publication.
  • publish --target ID requires every configured format for exactly those targets. Omitting it continues to require the complete configuration. Package hashes, recipe completion and configuration identity are still verified.
  • Native prerelease jobs can use --defer-recipes when their shared configuration contains stable AUR/Homebrew templates. Those recipes remain deferred and cannot be published for a prerelease.

Apple signing and notarization behavior is unchanged from 0.5.1.

Validated locally with 73 tests and 465 assertions, isolated gem installation and workflow lint. The release workflow additionally runs native package acceptance before publishing the tested gem.

Full changelog: v0.5.1...v0.6.0

native-packages 0.5.1

Choose a tag to compare

@crmne crmne released this 13 Sep 21:18
v0.5.1
5caecbb

Apple signing now works on clean macOS CI runners, including portable Go executables. This patch also keeps separate packaging configurations from cancelling each other while queued.

  • Register the temporary signing keychain in the user search list while preserving existing entries and the default keychain. Delete only the owned keychain afterward.
  • Coordinate signing calls under the same OS user so parallel packaging hooks cannot race keychain search-list changes.
  • Give stable, alpha and macOS configurations independent reusable-workflow concurrency groups.

The signing failure was reproduced on a clean GitHub macOS runner with Go arm64, Go amd64 and a fresh Clang executable. All three signed successfully once the owned keychain was registered. All 69 tests and 425 assertions pass, including regressions for registration, cleanup after success/failure, preservation of other keychains, and the shared signing lock. Isolated gem installation and native Mac lock tests also pass.

The CLI and six Apple environment variable names are unchanged. Pin the 0.5.1 gem and its corresponding workflow commit for the fixes.

Full changelog

native-packages 0.5.0

Choose a tag to compare

@crmne crmne released this 13 Sep 20:35
v0.5.0
5776754

Native macOS packages can now be signed and notarized automatically when the Apple credentials are configured in CI.

  • Native DMG builds sign an owned copy of the app and its nested code, preserve existing entitlements, submit the image to Apple, staple and validate the ticket, then record final checksums.
  • Use notarize-macos INPUT --output OUTPUT to prepare a signed, notarized portable directory before creating a tarball. Standalone executables use Gatekeeper's online ticket lookup; app bundles receive stapled tickets.
  • Imported certificates and notarization credentials use a disposable keychain. Partial credential configuration fails clearly; absent Apple credentials retain existing local behavior. Linux and Windows packaging remain independent.
  • Application-owned DMG recipes and output hooks still run, with signatures ready before packaging and notarization completed after hooks. See the setup and migration guide.

Validated with 67 tests and 410 assertions, isolated gem installation, green hosted Linux/macOS/Windows package lifecycle checks, a real Fastpotify universal DMG accepted by Apple and Gatekeeper, and a newly compiled portable executable/dylib/app fixture accepted and executed on Apple Silicon. These packaging checks do not replace application feature or Intel execution tests.

Full changelog

native-packages 0.4.0

Choose a tag to compare

@crmne crmne released this 13 Sep 18:28
9d9e1d4

Native packages can now be built on separate hosts before generating AUR and Homebrew recipes from the completed packages. This lets a recipe use the checksum of a DMG or installer produced during the same release.

  • Use build --defer-recipes on each native host, then aggregate --finalize-recipes once all targets are available.
  • Deferred builds no longer require unrelated recipe assets or AUR tooling. Selected package inputs, architecture checks and signing hooks still apply.
  • Finalization verifies matching configuration, release metadata, checksums and the complete target set. Unfinished recipes cannot be published.
  • Existing builds retain their current behavior when the new flags are absent.

Validated with 58 unit and package integration tests, isolated gem installation, real Fastpotify DEB/RPM and recipe output comparisons, and native Linux/macOS/Windows package lifecycle checks.

Full changelog

native-packages 0.3.1

Choose a tag to compare

@crmne crmne released this 13 Sep 17:34
v0.3.1
4c0f54e

Fix aggregation of packages built on different computers or in separate checkout directories.

Version 0.3.0 persisted the checkout-local ROOT token into shared release metadata. Linux, macOS and Windows builds consequently produced conflicting recipes/release.json files despite identical source configuration and release inputs. ROOT remains available while building and rendering templates, but is now omitted from persisted release metadata.

A regression builds two targets in different checkout directories and verifies their combined manifest. The complete local suite passes 50 tests and 290 assertions; an isolated gem installation, initialization, validation and build also pass.

Update configurations from 0.3.0 to 0.3.1 and rebuild the affected target manifests before aggregation. Existing 0.3.0 artifacts are preserved; this patch does not rewrite published packages or release tags.

Install: gem install native-packages --version 0.3.1

native-packages 0.3.0

Choose a tag to compare

@crmne crmne released this 13 Sep 17:15
v0.3.0
304beac

Native-packages can now coordinate application-owned macOS DMG and Windows Inno Setup recipes alongside Linux packages, with one build manifest and checksum workflow.

  • Opt into alpha.N, beta.N, and rc.N versions for DEB, RPM, DMG and Inno. Defaults and legacy commands remain stable-only; preview uploads require an existing GitHub prerelease.
  • Preserve complete native payloads, internal bundle symlinks and file permissions. Check architecture, copied input integrity, recipe output and final checksums; reject input mutation and unsafe links.
  • Run application signing and notarization hooks before recording package hashes, then aggregate complete target results for publication.
  • Handle native command output correctly across text locales.

Validation passed on Ruby 3.4 and 4.0, Linux package lifecycle checks, Windows MSIX and Inno fixtures, and macOS DMG fixtures. Native fixtures cover installation, upgrade, rollback and removal; each application still needs its own platform acceptance tests.

Existing consumers pinned to 0.2.0 are unchanged. Ruby 3.2 or newer remains required; no runtime gem dependencies were added.

Install: gem install native-packages --version 0.3.0

See native recipe configuration for the new opt-in interfaces.

native-packages 0.2.0

Choose a tag to compare

@crmne crmne released this 13 Sep 08:59
4ddc144

Installable packaging CLI with one native-packages.yaml configuration. Adds init, doctor, build, aggregate, publish and migration while preserving the v0.1 interface.

  • Exposes DEB, RPM, Arch, APK, IPK, MSIX and SRPM through nFPM.
  • Uses explicit local or verified release inputs, ELF/PE validation, native package filenames and build manifests.
  • Supports existing native signing commands through after_package.
  • Reuses downstream recipe and repository automation without per-application Gemfiles or wrapper scripts.

The release workflow follows RubyLLM: publishing this GitHub release runs checks and publishes the tested gem using the repository's RUBYGEMS_AUTH_TOKEN secret. The gem is not available on RubyGems until that workflow succeeds.

MSIX installation uses Windows SDK SignTool; Windows rejected nFPM 2.47.0's built-in signature in the acceptance test. IPK acceptance targets OpenWrt 24.10.8; newer OpenWrt releases use APK. Application-specific compatibility and installation still need testing.