fix: drop v prefix from release tags

[RaulSMS]

Summary

• Update publish.yml tag trigger from v* to plain semver patterns ([0-9]+.[0-9]+.[0-9]+ and [0-9]+.[0-9]+.[0-9]+-*), so release tags no longer need a v prefix.
• Update CONTRIBUTING.md release instructions to match the new tag format.

Closes #70

Note

The "Release to PyPI" tag ruleset (refs/tags/v*, restricting who can push release tags) is a repo setting, not something changeable via this PR — it needs to be updated separately (e.g. to refs/tags/[0-9]*) so the new tag pattern is still gated to maintainers.

Test plan

• Confirm the ruleset pattern is updated in repo settings before cutting the next release
• Cut a test release with a plain semver tag (e.g. 0.1.3) and confirm publish.yml triggers and completes successfully

[RaulSMS]

Rulset to protect unwonted release trigger is updated to:

This is intentionally simpler/broader than the two workflow patterns — it just says "any tag starting with a digit," which covers 1.2.3 and 1.2.3-rc1 alike.

[RaulSMS]

On reflection, I'd recommend against merging this and keeping the v prefix on release tags.

Reasons:

• It's the ecosystem default. v-prefixed tags are the convention across the GitHub ecosystem — release-please (e.g. v17.11.2), semantic-release, and most GitHub Releases tooling default to it. Dropping it makes this repo the exception rather than the norm.
• Tags and PyPI versions are already separate namespaces, and that's fine. A tag v1.2.3 producing a PyPI version 1.2.3 is completely standard — PyPI version strings never include v regardless of what the tag looks like. There's no technical requirement driving the original ask; it was a personal preference from the reporter.
• Forward compatibility with Derive package version from git tag via setuptools-scm (stop hand-maintaining j1939/version.py) #79. If we move to setuptools-scm (proposed in Derive package version from git tag via setuptools-scm (stop hand-maintaining j1939/version.py) #79) to derive the version from the tag automatically, its default tag-parsing regex expects a v prefix (v(?P<version>...)). Keeping v* here means Derive package version from git tag via setuptools-scm (stop hand-maintaining j1939/version.py) #79 works with zero extra config; dropping it means adding custom regex config to setuptools-scm for no benefit.
• Clearer disambiguation. v1.2.3 is unambiguously a release tag at a glance, distinct from any other numeric ref.

Given this, I think the better fix for #70's actual underlying concern (the ruleset pattern) is to leave the v* tag format as-is. Closing this PR without merging unless there's a strong reason to prefer the plain-semver form.

[RaulSMS]

@sharma9012mahesh please see the latest comment, I don't think we should merge this.

[sharma9012mahesh]

@sharma9012mahesh please see the latest comment, I don't think we should merge this.

Guess you got a strong argument. Makes sense to drop if off then!