Release 4.4.79 — dependency bumps and stable package manifest

Overview

This release contains metadata and dependency updates only: the package.json version is moved from a pre-release token to a stable patch release, and several @fjell-scoped package dependencies are bumped. No runtime/source files were modified in this change set — the commits modify only package.json entries. The main practical effects are on publishing semantics and dependency resolution for downstream consumers.

Breaking Changes

• None in source code. The changes are limited to package.json and do not alter runtime code paths (commits: bd96d46, 69421af).

What changed (details and rationale)

• Publish/version metadata: replaced pre-release version string with a stable patch version in package.json (commit bd96d46).

  • What changed: package.json version was changed from "4.4.79-dev.0" to "4.4.79".
  • Why it matters: registries and package managers will treat this as a stable semver release rather than a pre-release. This affects which version is resolved when downstream projects request version ranges that exclude pre-releases and influences publish tooling that expects a canonical semver.
  • User action: no code changes required; when publishing, confirm the CI/publish pipeline uses the updated package.json and that any downstream lockfiles are refreshed if necessary.

• Dependency bumps in package.json (commit 69421af).

  • What changed: conservative semver updates to several @fjell packages were applied in package.json:
    • "@fjell/core": "^4.4.74" -> "^4.4.76"
    • "@fjell/lib": "^4.4.84" -> "^4.4.86"
    • "@fjell/registry": "^4.4.82" -> "^4.4.83"
    • "@fjell/types": "^4.4.5" -> "^4.4.6"
    • "@fjell/validation": "^4.4.2" -> "^4.4.3"
  • Why it matters: these bumps are intended to bring in downstream bug fixes or minor improvements from those packages. Because they are dependency manifest changes only, they may change runtime behavior or type resolution indirectly if any of those packages modified APIs or fixed bugs.
  • Impact & recommended actions:
    • Run the full test suite and any integration or smoke tests that exercise interactions with the @fjell packages to detect changes in behavior (the commit explicitly advises running CI and tests).
    • If your project pins transitive dependencies via a lockfile, regenerate and commit the lockfile (npm/yarn/pnpm) so installs are reproducible for CI and downstream consumers.

• Addition of a runtime logging dependency: "@fjell/logging" added to dependencies (commit 69421af).

  • What changed: package.json now lists "@fjell/logging": "^4.4.66" in dependencies.
  • Why it matters: introducing a runtime dependency can surface new public APIs and may increase the installed package footprint. The commit message notes this explicitly: "Adding @fjell/logging makes the logging package available at runtime and may surface new runtime APIs/dependencies for code that imports it."
  • Impact & recommended actions:
    • Verify that any code paths importing logging (directly or transitively) behave as expected. If your build or runtime environment restricts additional packages, ensure the new dependency is acceptable.
    • If you vendor or audit dependencies, include @fjell/logging in those checks before publishing/upgrading.

Notes about scope and risks

• Scope: All commits are limited to package.json; there are no source code changes in this release (commits: bd96d46, 69421af). The earlier dev-version commit (56facd1) shows the pre-release token that was replaced.

• Risks: Because dependency versions changed and a new runtime dependency was added, the primary risks are:

  • Subtle behavioral differences from updated @fjell packages that only surface during integration/runtime (not visible in source diffs).
  • Publish/semver consequences if the package was previously referenced as a pre-release by downstream projects that explicitly depended on the dev tag — those consumers will need to update their dependency specifier if they intended to continue tracking a pre-release channel.

Migration and verification checklist

• For maintainers preparing to publish:

  • Ensure CI/publish steps point at the updated package.json and that the publish run is performed from a clean working tree (commit: bd96d46).
  • Confirm registry behavior for the new stable version (e.g., npm view) and verify tags if you publish both stable and pre-release channels.

• For downstream consumers/upgraders:

  • Update lockfiles and reinstall to pick up the new dependency manifest.
  • Run tests and integration checks that exercise interactions with @fjell packages and any logging-related code paths.
  • If you intentionally depended on the pre-release token ("-dev"), decide whether to remain on the previous pre-release or upgrade to the stable 4.4.79 release.

Commits

• Bump package manifest version from pre-release to stable in package.json (bd96d46)
• Bump @fjell package dependency versions in package.json and add @fjell/logging (69421af)
• Pre-release/placeholder commit showing dev version (56facd1)

If you need a short checklist or an automated script suggestion for regenerating lockfiles and running a smoke test matrix against the updated dependencies, say so and a suggested script will be provided.