Publish-ready patch: version set to 4.4.2 and two internal deps bumped

Overview

This release contains only package metadata updates: the package version is moved from a development tag to a canonical patch release string, and two internal @fjell dependencies are advanced by one patch level. There are no source-code changes in this release; the changes affect how the package is resolved, published, and installed.

Breaking changes

• None in source code. All changes are metadata-only and intended to be backward-compatible. (See commits ee1619b and b53cec0 for details.)

Notable changes

• Set canonical release version (commit ee1619b)

  • What changed: package.json version value was changed from a development/tagged string to "4.4.2".
  • Why it matters: this moves the package from a dev snapshot identity to a semantically-versioned patch release. Consumers and tooling (npm/yarn, changelog generators, CI publishing pipelines) will treat this as a stable 4.4.2 release instead of a dev snapshot, which affects resolution, publishing behavior, and semver comparisons.
  • Implications: downstream projects that pinned or resolved the dev-tag version may need to refresh lockfiles; publishers should verify packaging and CI publish steps now produce the intended release artifacts.

• Bump internal dependencies (commit b53cec0)

  • What changed: package.json dependency entries updated:
    • "@fjell/logging" updated from ^4.4.65 → ^4.4.66
    • "@fjell/types" updated from 4.4.4 → 4.4.5
  • Why it matters: these are patch-level updates of internal packages. The caret-range bump for @fjell/logging allows newer patch resolution within 4.x, while @fjell/types was advanced as a fixed patch.
  • Implications: although patch bumps are expected to be backward-compatible, they can affect type resolution, build outputs, or runtime behavior if the bumped packages contained fixes or small contract adjustments. To pick up the new versions consumers will need to regenerate lockfiles (npm/yarn) and reinstall; CI should run full test suites to validate compatibility.

What to do after upgrading (practical guidance)

• Update lockfile and reinstall dependencies: regenerate package-lock.json or yarn.lock and run a fresh install. The package.json changes will not take effect for consumers until lockfiles are updated.
• Run the test suite and any downstream build steps: since the changes are dependency bumps and a version move, run tests to ensure no typing/build regressions occur from the updated @fjell/types and @fjell/logging packages.
• If you pin the dev-tag version in CI or scripts, switch to the released version string (4.4.2) to avoid resolving the previous dev snapshot.
• For maintainers: verify CI publish flow treats this as a stable release (pack/publish), and confirm changelog/generator tooling recognizes 4.4.2 rather than a dev tag.

Technical details (traceable commits)

• Bump package version metadata from dev tag to concrete patch release (commit ee1619b)

  • "Update package.json: replace "version": "4.4.2-dev.0" with "version": "4.4.2""
  • Notes in commit message emphasize this is metadata-only and that lockfile/publish tooling may need attention.

• Bump two internal package dependencies to their next patch versions in package.json (commit b53cec0)

  • "Update dependency "@fjell/logging" in package.json from ^4.4.65 to ^4.4.66"
  • "Update dependency "@fjell/types" in package.json from 4.4.4 to 4.4.5"
  • Commit message calls out caret semantics for @fjell/logging and the exact pin for @fjell/types and recommends lockfile update and tests to validate compatibility.

Context and pattern

These commits together form a small, focused release whose goal is to promote the current development snapshot to a proper patch release and to align internal dependency pins to the latest patch versions. The pattern is typical for a maintenance patch: no code-level fixes here, but ecosystem-facing metadata and dependency hygiene that ensure consumers and publishing tooling see a canonical release. The main downstream effects are around dependency resolution (lockfiles) and publish behavior—not API changes.

If you maintain downstream packages, prioritize regenerating lockfiles and running CI to confirm nothing unexpected appears after the dependency bumps.