Should `core_version` stay, or should we follow the more common action patterns?

[marcalexiei]

Opening this for discussion (thinking about it while working on #113).

Because core_version lets callers pick the internal core version at run time, the action has to stay a composite action that installs from npm on every invocation.
Most actions instead let their own ref be the version (uses: org/action@v2, a SHA) and ship the code bundled, with ncc compiling into a committed dist/index.js, using: node24, and a check-dist job as a guard.

There's also a coupling argument: index.js expects specific core exports and a { content, status } result, so a core_version outside that range breaks the action's own code rather than the caller's configuration. latest would do exactly that the day a v3 renames an export.
fail_on_error is the quieter version of the problem, since it reads result.status, which older cores don't return, so an older core_version silently makes the flag a no-op.

If we wanted to move that way:

• Remove the core_version input; pin core in package.json only.
• Bundle and switch to using: node24, dropping the install steps from action.yml.
• Ship core updates through automation, since dependabot already opens the bump PR: a release on merge plus update-tags.yml would carry it to users on @v1.

Against that: it's breaking for anyone setting core_version, whose replacement would be an exact tag or SHA, and a committed dist/ adds review noise and a stale-bundle failure mode.

If people rely on the input, leaving things as they are seems reasonable.

[martin-mfg]

Thanks for the suggestion.

I agree that the suggested change has some advantages and some disadvantages. Generally I am slightly in favor of making the change. But it is a breaking change, and I think it's currently not worth it to cause trouble/work for users with a major release just for this breaking change. I'd rather wait for more reasons to create a new major version.

---

Another benefit of making the suggested change is that it avoids dependency drift.

index.js expects specific core exports and a { content, status } result, so a core_version outside that range breaks the action's own code rather than the caller's configuration. latest would do exactly that the day a v3 renames an export

github-stats-extended uses semantic versioning, so breaking changes come with a major version upgrade. Users who configure a version like "latest", i.e. across major versions, knowlingly take this risk.

Note for my future self: "check-dist" refers to this.

[marcalexiei]

I think it's currently not worth it to cause trouble/work for users with a major release just for this breaking change. I'd rather wait for more reasons to create a new major version.

Fine by me. Once we have a breaking change to release we can switch to the action standard approach.