simp / simp/rubygem-simp-rake-helpers

Two divergent CHANGELOG_ENTRY_REGEX constants disagree on what is a valid entry

Open
#272 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Ruby
Stars
3
Forks
10
Avg merge
4d 21h
Merged PRs (30d)
4

Description

Follow-up from review of #271.

There are two CHANGELOG_ENTRY_REGEX constants, and after #271 the two tasks that consume them disagree about what counts as a valid CHANGELOG entry.

Simp::ComponentInfo (componentinfo.rb:22) Simp::Rake::Pupmod::Helpers (helpers.rb:38)
day [0-3][0-9] — zero-padded only \d{1,2} — single digit allowed
separator before version required optional
end anchor \s*$ none, trailing junk allowed
release qualifier captured (group 4) not captured

Consumers: pkg:check_version and Simp::RelChecks use the ComponentInfo one; the deprecated top-level compare_latest_tag and changelog_annotation use the Helpers one.

So an entry like

* Mon Aug 4 2026 Some One <someone@simp-project.com> - 1.2.3

is accepted by compare_latest_tag but rejected by pkg:check_version. The divergence is currently spec-locked in both directions — componentinfo_changelog_regex_spec.rb asserts a single-digit day does not match, helpers_spec.rb asserts it does — so neither can be changed without deciding which behavior is intended.

Why this matters

#270 was caused by a third, ad hoc copy of this regex drifting from the canonical one. #271 removed that copy, but the two remaining constants are the same hazard in slower motion.

Suggested resolution

Decide the intended day/separator/anchoring semantics, then make Simp::Rake::Pupmod::Helpers::CHANGELOG_ENTRY_REGEX an alias of Simp::ComponentInfo::CHANGELOG_ENTRY_REGEX. The capture-group indices are already compatible (1 date, 2 author, 3 version), so consumers need no changes beyond the constant itself.

Worth noting the RPM changelog convention is a zero-padded day, and Simp::ComponentInfo already enforces that on the same files elsewhere in the gem — so standardising on the stricter form is likely correct, but it would start rejecting entries that compare_latest_tag accepts today, which is why this is filed for a decision rather than folded into #271.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with componentinfo.rb:22 and helpers.rb:38, then read componentinfo_changelog_regex_spec.rb and helpers_spec.rb alongside the pkg:check_version and deprecated helper consumers. Decide the intended day, separator, anchoring, and qualifier semantics, consolidate the constants accordingly, update the conflicting specs, and run the affected test suite with both accepted and rejected changelog examples.

Written by the indexing model from the issue text.

Assessment

Tech stack
ruby
Domain
tooling
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.